<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>Suborigins</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) and (display:contents) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge {
		/* Magic to create good table positioning:
		   "content column" is 50ems wide at max; less on smaller screens.
		   Extra space (after ToC + content) is empty on the right.

		   1. When table < content column, centers table in column.
		   2. When content < table < available, left-aligns.
		   3. When table > available, fills available + scroll bar.
		*/ 
		display: grid;
		grid-template-columns: minmax(0, 50em);
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
  <link href="https://w3c.github.io/webappsec-suborigins/" rel="canonical">
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
<style>/* style-dfn-panel */

.dfn-panel {
    position: absolute;
    z-index: 35;
    height: auto;
    width: -webkit-fit-content;
    width: fit-content;
    max-width: 300px;
    max-height: 500px;
    overflow: auto;
    padding: 0.5em 0.75em;
    font: small Helvetica Neue, sans-serif, Droid Sans Fallback;
    background: #DDDDDD;
    color: black;
    border: outset 0.2em;
}
.dfn-panel:not(.on) { display: none; }
.dfn-panel * { margin: 0; padding: 0; text-indent: 0; }
.dfn-panel > b { display: block; }
.dfn-panel a { color: black; }
.dfn-panel a:not(:hover) { text-decoration: none !important; border-bottom: none !important; }
.dfn-panel > b + b { margin-top: 0.25em; }
.dfn-panel ul { padding: 0; }
.dfn-panel li { list-style: inside; }
.dfn-panel.activated {
    display: inline-block;
    position: fixed;
    left: .5em;
    bottom: 2em;
    margin: 0 auto;
    max-width: calc(100vw - 1.5em - .4em - .5em);
    max-height: 30vh;
}

.dfn-paneled { cursor: pointer; }
</style>
<style>/* style-syntax-highlighting */
pre.idl.highlight { color: #708090; }
.highlight:not(.idl) { background: hsl(24, 20%, 95%); }
code.highlight { padding: .1em; border-radius: .3em; }
pre.highlight, pre > code.highlight { display: block; padding: 1em; margin: .5em 0; overflow: auto; border-radius: 0; }
c-[a] { color: #990055 } /* Keyword.Declaration */
c-[b] { color: #990055 } /* Keyword.Type */
c-[c] { color: #708090 } /* Comment */
c-[d] { color: #708090 } /* Comment.Multiline */
c-[e] { color: #0077aa } /* Name.Attribute */
c-[f] { color: #669900 } /* Name.Tag */
c-[g] { color: #222222 } /* Name.Variable */
c-[k] { color: #990055 } /* Keyword */
c-[l] { color: #000000 } /* Literal */
c-[m] { color: #000000 } /* Literal.Number */
c-[n] { color: #0077aa } /* Name */
c-[o] { color: #999999 } /* Operator */
c-[p] { color: #999999 } /* Punctuation */
c-[s] { color: #a67f59 } /* Literal.String */
c-[t] { color: #a67f59 } /* Literal.String.Single */
c-[u] { color: #a67f59 } /* Literal.String.Double */
c-[cp] { color: #708090 } /* Comment.Preproc */
c-[c1] { color: #708090 } /* Comment.Single */
c-[cs] { color: #708090 } /* Comment.Special */
c-[kc] { color: #990055 } /* Keyword.Constant */
c-[kn] { color: #990055 } /* Keyword.Namespace */
c-[kp] { color: #990055 } /* Keyword.Pseudo */
c-[kr] { color: #990055 } /* Keyword.Reserved */
c-[ld] { color: #000000 } /* Literal.Date */
c-[nc] { color: #0077aa } /* Name.Class */
c-[no] { color: #0077aa } /* Name.Constant */
c-[nd] { color: #0077aa } /* Name.Decorator */
c-[ni] { color: #0077aa } /* Name.Entity */
c-[ne] { color: #0077aa } /* Name.Exception */
c-[nf] { color: #0077aa } /* Name.Function */
c-[nl] { color: #0077aa } /* Name.Label */
c-[nn] { color: #0077aa } /* Name.Namespace */
c-[py] { color: #0077aa } /* Name.Property */
c-[ow] { color: #999999 } /* Operator.Word */
c-[mb] { color: #000000 } /* Literal.Number.Bin */
c-[mf] { color: #000000 } /* Literal.Number.Float */
c-[mh] { color: #000000 } /* Literal.Number.Hex */
c-[mi] { color: #000000 } /* Literal.Number.Integer */
c-[mo] { color: #000000 } /* Literal.Number.Oct */
c-[sb] { color: #a67f59 } /* Literal.String.Backtick */
c-[sc] { color: #a67f59 } /* Literal.String.Char */
c-[sd] { color: #a67f59 } /* Literal.String.Doc */
c-[se] { color: #a67f59 } /* Literal.String.Escape */
c-[sh] { color: #a67f59 } /* Literal.String.Heredoc */
c-[si] { color: #a67f59 } /* Literal.String.Interpol */
c-[sx] { color: #a67f59 } /* Literal.String.Other */
c-[sr] { color: #a67f59 } /* Literal.String.Regex */
c-[ss] { color: #a67f59 } /* Literal.String.Symbol */
c-[vc] { color: #0077aa } /* Name.Variable.Class */
c-[vg] { color: #0077aa } /* Name.Variable.Global */
c-[vi] { color: #0077aa } /* Name.Variable.Instance */
c-[il] { color: #000000 } /* Literal.Number.Integer.Long */
</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"><a class="logo" href="https://www.w3.org/"> <img alt="W3C" height="48" src="https://www.w3.org/StyleSheets/TR/2016/logos/W3C" width="72"> </a> </p>
   <h1 class="p-name no-ref" id="title">Suborigins</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="1970-01-01">1 January 1970</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>This version:
     <dd><a class="u-url" href="https://w3c.github.io/webappsec-suborigins/">https://w3c.github.io/webappsec-suborigins/</a>
     <dt>Feedback:
     <dd><span><a href="mailto:public-webappsec@w3.org?subject=%5Bsuborigins%5D%20YOUR%20TOPIC%20HERE">public-webappsec@w3.org</a> with subject line “<kbd>[suborigins] <i data-lt>… message topic …</i></kbd>” (<a href="https://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)</span>
     <dt class="editor">Editors:
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-url url" href="https://joelweinberger.us">Joel Weinberger</a> (<span class="p-org org">Google Inc.</span>) <a class="u-email email" href="mailto:jww@google.com">jww@google.com</a>
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-url url" href="http://devd.me">Devdatta Akhawe</a> (<span class="p-org org">Dropbox Inc.</span>) <a class="u-email email" href="mailto:dev.akhawe@gmail.com">dev.akhawe@gmail.com</a>
     <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:eisinger@google.com">Jochen Eisinger</a> (<span class="p-org org">Google Inc.</span>)
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <p class="copyright" data-fill-with="copyright"><a href="https://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 1970 <a href="https://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="https://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="https://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="https://www.keio.ac.jp/">Keio</a>, <a href="https://ev.buaa.edu.cn/">Beihang</a>). W3C <a href="https://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply. </p>
   <hr title="Separator for header">
  </div>
  <div class="p-summary" data-fill-with="abstract">
   <h2 class="no-num no-toc no-ref heading settled" id="abstract"><span class="content">Abstract</span></h2>
   <p>This specification defines a mechanism for programmatically defining origins

  to isolate different applications running in the same physical origin. It
  allows a server to specify a namespace on a resource response which is paired
  with the scheme/host/port origin tuple. User agents extend the same-origin
  policy with this new namespace plus origin tuple to create a security
  boundary between this resource and resources in other namespaces.</p>
  </div>
  <h2 class="no-num no-toc no-ref heading settled" id="status"><span class="content">Status of this document</span></h2>
  <div data-fill-with="status">
   <p> This is a public copy of the editors’ draft.
	It is provided for discussion only and may change at any moment.
	Its publication here does not imply endorsement of its contents by W3C.
	Don’t cite this document other than as work in progress. </p>
   <p> <strong>Changes to this document may be tracked at <a href="https://github.com/w3c/webappsec">https://github.com/w3c/webappsec</a>.</strong> </p>
   <p> The (<a href="https://lists.w3.org/Archives/Public/public-webappsec/">archived</a>) public mailing list <a href="mailto:public-webappsec@w3.org?Subject=%5Bsuborigins%5D%20PUT%20SUBJECT%20HERE">public-webappsec@w3.org</a> (see <a href="https://www.w3.org/Mail/Request">instructions</a>)
	is preferred for discussion of this specification.
	When sending e-mail,
	please put the text “suborigins” in the subject,
	preferably like this:
	“[suborigins] <em>…summary of comment…</em>” </p>
   <p> This document was produced by the <a href="https://www.w3.org/2011/webappsec/">Web Application Security Working Group</a>. </p>
   <p> This document was produced by a group operating under
	the <a href="https://www.w3.org/Consortium/Patent-Policy/">W3C Patent Policy</a>.
	W3C maintains a <a href="https://www.w3.org/2004/01/pp-impl/49309/status" rel="disclosure">public list of any patent disclosures</a> made in connection with the deliverables of the group;
	that page also includes instructions for disclosing a patent.
	An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
   <p> This document is governed by the <a href="https://www.w3.org/2019/Process-20190301/" id="w3c_process_revision">1 March 2019 W3C Process Document</a>. </p>
   <p></p>
  </div>
  <div data-fill-with="at-risk"></div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li>
     <a href="#intro"><span class="secno">1</span> <span class="content">Introduction</span></a>
     <ol class="toc">
      <li><a href="#goals"><span class="secno">1.1</span> <span class="content">Goals</span></a>
      <li><a href="#usecases"><span class="secno">1.2</span> <span class="content">Use Cases/Examples</span></a>
     </ol>
    <li>
     <a href="#terms"><span class="secno">2</span> <span class="content">Key Concepts and Terminology</span></a>
     <ol class="toc">
      <li><a href="#grammar"><span class="secno">2.1</span> <span class="content">Grammatical Concepts</span></a>
     </ol>
    <li>
     <a href="#defining-suborigin"><span class="secno">3</span> <span class="content">Defining a Suborigin</span></a>
     <ol class="toc">
      <li>
       <a href="#difficulties"><span class="secno">3.1</span> <span class="content">Difficulties using subdomains</span></a>
       <ol class="toc">
        <li><a href="#separate-applications-same-origin"><span class="secno">3.1.1</span> <span class="content">Separate applications, same origin</span></a>
        <li><a href="#separation-in-single-application"><span class="secno">3.1.2</span> <span class="content">Separation within a single application</span></a>
       </ol>
      <li>
       <a href="#threat-model"><span class="secno">3.2</span> <span class="content">Threat Model</span></a>
       <ol class="toc">
        <li><a href="#threat-model-cross-doc"><span class="secno">3.2.1</span> <span class="content">Cross-Document Attacker</span></a>
        <li><a href="#threat-model-out-of-scope"><span class="secno">3.2.2</span> <span class="content">Out of Scope Attacker</span></a>
       </ol>
      <li><a href="#suborigins-vs-origins"><span class="secno">3.3</span> <span class="content">Relationship of Suborigins to Origins</span></a>
      <li><a href="#opting-in"><span class="secno">3.4</span> <span class="content">Opting into a Suborigin</span></a>
      <li><a href="#the-suborigin-header"><span class="secno">3.5</span> <span class="content">The <code>suborigin</code> header</span></a>
      <li><a href="#representation"><span class="secno">3.6</span> <span class="content">Representation of Suborigins</span></a>
      <li><a href="#suborigin-in-js"><span class="secno">3.7</span> <span class="content">Accessing the Suborigin in JavaScript</span></a>
     </ol>
    <li>
     <a href="#access-control"><span class="secno">4</span> <span class="content">Access Control</span></a>
     <ol class="toc">
      <li><a href="#cors-ac"><span class="secno">4.1</span> <span class="content">CORS</span></a>
      <li><a href="#postmessage-ac"><span class="secno">4.2</span> <span class="content"><code>postMessage</code></span></a>
      <li><a href="#workers-ac"><span class="secno">4.3</span> <span class="content">Workers</span></a>
     </ol>
    <li>
     <a href="#impact"><span class="secno">5</span> <span class="content">Impact on Web Platform</span></a>
     <ol class="toc">
      <li><a href="#storage"><span class="secno">5.1</span> <span class="content">Storage</span></a>
      <li><a href="#document-domain"><span class="secno">5.2</span> <span class="content"><code>document.domain</code></span></a>
      <li><a href="#websockets"><span class="secno">5.3</span> <span class="content">WebSockets</span></a>
     </ol>
    <li>
     <a href="#framework"><span class="secno">6</span> <span class="content">Framework</span></a>
     <ol class="toc">
      <li>
       <a href="#origin-updates"><span class="secno">6.1</span> <span class="content">Updates to Origin</span></a>
       <ol class="toc">
        <li><a href="#suborigin-of-response"><span class="secno">6.1.1</span> <span class="content">Suborigin of a Response</span></a>
        <li><a href="#origin-tuple"><span class="secno">6.1.2</span> <span class="content">Origin Tuple</span></a>
        <li><a href="#physical-origin-concept"><span class="secno">6.1.3</span> <span class="content">Physical Origin</span></a>
        <li><a href="#comparing-origins"><span class="secno">6.1.4</span> <span class="content">Comparing Origins</span></a>
        <li><a href="#comparing-physical-origins"><span class="secno">6.1.5</span> <span class="content">Comparing Physical Origins</span></a>
        <li>
         <a href="#serializing"><span class="secno">6.1.6</span> <span class="content">Serializing Suborigins</span></a>
         <ol class="toc">
          <li><a href="#unicode-serialization"><span class="secno">6.1.6.1</span> <span class="content">Unicode Serialization of a Suborigin</span></a>
          <li><a href="#ascii-serialization"><span class="secno">6.1.6.2</span> <span class="content">ASCII Serialization of a Suborigin</span></a>
          <li><a href="#document-origin"><span class="secno">6.1.6.3</span> <span class="content"><code>Document</code> object’s origin</span></a>
         </ol>
       </ol>
      <li>
       <a href="#dom-interactions"><span class="secno">6.2</span> <span class="content">Interactions with the DOM</span></a>
       <ol class="toc">
        <li><a href="#cookies"><span class="secno">6.2.1</span> <span class="content">Cookies</span></a>
       </ol>
      <li>
       <a href="#security-model-opt-outs"><span class="secno">6.3</span> <span class="content">Security Model Opt-Outs</span></a>
       <ol class="toc">
        <li><a href="#unsafe-postmessage-receive"><span class="secno">6.3.1</span> <span class="content"><code>'unsafe-postmessage-receive'</code></span></a>
        <li><a href="#unsafe-postmessage-send"><span class="secno">6.3.2</span> <span class="content"><code>'unsafe-postmessage-send'</code></span></a>
        <li><a href="#unsafe-cookies"><span class="secno">6.3.3</span> <span class="content"><code>'unsafe-cookies'</code></span></a>
        <li><a href="#unsafe-credentials"><span class="secno">6.3.4</span> <span class="content"><code>'unsafe-credentials'</code></span></a>
       </ol>
     </ol>
    <li><a href="#practical-considerations"><span class="secno">7</span> <span class="content">Practical Considerations in Using Suborigins</span></a>
    <li>
     <a href="#security-considerations"><span class="secno">8</span> <span class="content">Security Considerations</span></a>
     <ol class="toc">
      <li><a href="#presentation-to-users"><span class="secno">8.1</span> <span class="content">Presentation of Suborigins to Users</span></a>
      <li><a href="#not-overthrowing-sop"><span class="secno">8.2</span> <span class="content">Not Overthrowing Same-Origin Policy</span></a>
      <li><a href="#serialization-concerns"><span class="secno">8.3</span> <span class="content">Problems with Serialized Representation</span></a>
     </ol>
    <li><a href="#privacy-considerations"><span class="secno">9</span> <span class="content">Privacy Considerations</span></a>
    <li>
     <a href="#conformance"><span class="secno"></span> <span class="content">Conformance</span></a>
     <ol class="toc">
      <li><a href="#conventions"><span class="secno"></span> <span class="content">Document conventions</span></a>
      <li><a href="#conformant-algorithms"><span class="secno"></span> <span class="content">Conformant Algorithms</span></a>
     </ol>
    <li>
     <a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
     <ol class="toc">
      <li><a href="#index-defined-here"><span class="secno"></span> <span class="content">Terms defined by this specification</span></a>
      <li><a href="#index-defined-elsewhere"><span class="secno"></span> <span class="content">Terms defined by reference</span></a>
     </ol>
    <li>
     <a href="#references"><span class="secno"></span> <span class="content">References</span></a>
     <ol class="toc">
      <li><a href="#normative"><span class="secno"></span> <span class="content">Normative References</span></a>
      <li><a href="#informative"><span class="secno"></span> <span class="content">Informative References</span></a>
     </ol>
    <li><a href="#idl-index"><span class="secno"></span> <span class="content">IDL Index</span></a>
    <li><a href="#issues-index"><span class="secno"></span> <span class="content">Issues Index</span></a>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="intro"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#intro"></a></h2>
   <p><em>This section is not normative.</em></p>
   <p>Currently, web applications are almost always compartmentalized by using
  separate host names to establish separate web origins. This is useful for
  helping to prevent XSS and other cross-origin attacks, but has many unintended
  consequences. For example, it causes latency due to additional DNS lookups,
  removes the ability to use single-origin features (such as the
  history.pushState API), and creates cryptic host name changes in the user
  experience. Perhaps most importantly, it results in an extremely inflexible
  architecture that, once rolled out, cannot be easily and transparently changed
  later on.</p>
   <p>There are several mechanisms for reducing the attack surface for XSS without
  creating separate host-name based origins, but each pose their own problems.
  Per-page Suborigins is an attempt to fill some of those gaps. Two of the most
  notable mechanisms are Sandboxed IFrames <a data-link-type="biblio" href="#biblio-iframesandbox">[IFrameSandbox]</a> and Content Security
  Policy (CSP) <a data-link-type="biblio" href="#biblio-csp2">[CSP2]</a>. Both are powerful but have shortcomings and there are
  external developers building legacy applications that find they cannot use
  those tools.</p>
   <p>Application developers can use sandboxed frames to completely isolate
  untrusted content, but there are a number of problems with such an approach.
  Since user agents assign sandboxed frames a random, unpredictable origin, it is
  very difficult, by design, for them to communicate with other frames or use
  modern, origin-bound mechanisms like <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage" id="ref-for-dom-messageport-postmessage">postMessage</a> and <a data-link-type="dfn" href="#cors" id="ref-for-cors">CORS</a>.
  Further, there is no easy way to persist client-side state (e.g., using <a data-link-type="dfn">localStorage</a> or <a data-link-type="dfn">sessionStorage</a>) in random, unpredictable origins.
  Finally, sandboxed frames not only sandbox the application but also any other
  frames loaded by the appplication. This makes this technique infeasible for any
  page relying on third-party integrations.  Moreover, because they are by
  definition unique origins, with no relationship to the original origin,
  designing permissions for them to access resources of the original origin would
  be difficult.</p>
   <p>Content Security Policy is also promising but is generally incompatible with
  current website design. Developers and security teams have found it impractical to retrofit
  legacy applications with it. On top of this, until all applications
  hosted within a single origin are simultaneously put behind CSP, the mechanism
  offers limited incremental benefits, which is especially problematic for
  companies with large portfolios of disparate products all under the same domain.</p>
   <h3 class="heading settled" data-level="1.1" id="goals"><span class="secno">1.1. </span><span class="content">Goals</span><a class="self-link" href="#goals"></a></h3>
   <ul>
    <li data-md>
     <p>Provide a way for different applications hosted on a single physical origin to
isolate these into separate logical origins. For example, <code>https://foobar.com/application</code> and <code>https://foobar.com/widget</code>, today, are,
by definition, in the same origin, even if they are different applications.
Thus an XSS at <code>https://foobar.com/application</code> means an XSS at <code>https://foobar.com/widget</code>, even if <code>https://foobar.com/widget</code> is
"protected" by a strong Content Security Policy. Suborigins should allow
isolating /application and /widget.</p>
    <li data-md>
     <p>Similarly, provide a way for content authors to split their applications
into logical modules with origin level separation without using different physical
origins. Content authors should not have to choose between putting all of
their content in the same origin, on different physical origins, or putting
content in anonymous unique origins (sandboxes).</p>
    <li data-md>
     <p>Provide safe defaults but also make it as simple as possible to retrofit
legacy applications on the same physical origin with minimal programmatic changes.
This includes providing security-model opt-outs where necessary.</p>
   </ul>
   <h3 class="heading settled" data-level="1.2" id="usecases"><span class="secno">1.2. </span><span class="content">Use Cases/Examples</span><a class="self-link" href="#usecases"></a></h3>
   <p>We see effectively three different use cases for Per-page Suborigins:</p>
   <ol>
    <li data-md>
     <p>Separating distinct applications served from the same domain due to
 deployment issues but do not need to extensively interact with other
 content. Examples include marketing campaigns, simple search UIs, and so on.</p>
    <li data-md>
     <p>Enable secure isolation at modular boundaries within a larger web
 application by splitting the functional components into different
 suborigins. For example, a blogging application might isolate the main blog
 viewership module, the admin module, and the authoring module via separate
 suborigins.</p>
    <li data-md>
     <p>Similar to (2), applications with many users can split information relating
 to different users into their own suborigin. For example, a social network
 might put each user profile into a unique suborigin so that an XSS within
 one profile cannot be used to immediately infect other users or read their
 personal messages stored within the account.</p>
   </ol>
   <div class="example" id="example-08ad93dd">
    <a class="self-link" href="#example-08ad93dd"></a> <code>https://example.com/</code> runs two applications, Chat and Shopping, used,
    respectively, for instant messaging and Internet shopping.  The site adminstrator runs 
    the former at <code>https://example.com/chat/</code>, and the latter at <code>https://example.com/shopping/</code>. 
    <p>The Shopping application has been very well tested and generally does not
    contain much untrusted content. In fact, it only takes simple text from
    advertisers, and that text only ever appears in HTML contexts, so the
    application is able to entity encode the text and stop nearly all cross-site
    scripting attacks on the application. Further, the developers have also
    enabled a strong Content Security Policy to mitigate potential XSS concerns
    on all pages under <code>https://example.com/shopping/</code>. The CSP policy only allows scripts
    from <code>scripts.example.com</code>.</p>
    <p>Historically, <code>https://example.com/chat/</code> has been riddled with cross-site
    scripting attacks. The application takes untrusted content from a wider
    variety of sources and for added complexity, that content ends up in many more
    contexts, such as HTML tag attributes. On top of that, the developers never
    bothered creating a CSP for the application.</p>
    <p>This is bad enough, but, unfortunately, it has led to the extremely bad
    consequence of attackers using the low hanging fruit of Chat to attack
    Shopping, the more desirable target. Cross-site scripting Shopping allows an
    attacker to buy goods with the user’s account, so this is really the juicy
    target.</p>
    <p>Since the applications share the same physical origin, these attacks have not
    traditionally been that difficult. Once an attacker has executed code on Chat
    with an XSS, they open a new window or iframe at <code>example.com/shopping/</code>.
    Since this is at the same origin as Chat, this allows the attacker to inject
    code through the <code>document</code> object of the window or iframe into the Shopping
    context, allowing the attacker to buy whatever they’d like.</p>
    <p>Historical and branding reasons require hosting both applications on the <code>example.com</code> origin. Thus, while these two applications are completely separate, the
    company cannot split the products into two different origins (e.g. <code>examplechat.com</code> and <code>exampleshopping.com</code>) or different suborigins (e.g. <code>chat.example.com</code> and <code>shopping.example.com</code>).</p>
    <p>To address this, the developers decide to serve both applications on two
    separate suborigins. For all HTTP requests to any subpath of <code>/chat</code> or <code>/shopping</code>, example.com includes a header <code>suborigin: chat</code> or <code>suborigin: shopping</code>, respectively.</p>
    <p>This does not remove any of the XSS attacks on Chat. However, when an attacker
    injects code into Chat and opens a window or iframe to <code>example.com/shopping/</code>, they can no longer inject content through the
    document as it will fail the same origin check. Of course, the application can
    still use <code>XMLHttpRequest</code> and <code>postMessage</code> to communicate with the document,
    but that will only be through well defined APIs.  In short, the CSP of the
    Shopping application is now actually effective as the permissive Chat
    application is no longer a bypass of it.</p>
   </div>
   <p class="issue" id="issue-21aaf26d"><a class="self-link" href="#issue-21aaf26d"></a> TODO: We probably should add additional examples, or perhaps match an
  example to each bullet above.</p>
   <h2 class="heading settled" data-level="2" id="terms"><span class="secno">2. </span><span class="content">Key Concepts and Terminology</span><a class="self-link" href="#terms"></a></h2>
   <p class="issue" id="issue-7af0036e"><a class="self-link" href="#issue-7af0036e"></a> TODO(jww) This needs to be filled in once we have a pretty good handle on
  the basic structure of this document. At that point, we should extract the terms
  defined throughout the spec and place them here.</p>
   <p>This section defines several terms used throughout the document.</p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="cors">CORS</dfn>, or <dfn data-dfn-type="dfn" data-noexport id="cross-origin-resource-sharing">Cross-Origin Resource Sharing<a class="self-link" href="#cross-origin-resource-sharing"></a></dfn>, are defined by the
  CORS specification. <a data-link-type="biblio" href="#biblio-cors">[CORS]</a></p>
   <p><dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="xmlhttprequest">XMLHttpRequest</dfn>, or <dfn data-dfn-type="dfn" data-noexport id="xhr">XHR<a class="self-link" href="#xhr"></a></dfn>, is defined by the XMLHttpRequest
  specification. <a data-link-type="biblio" href="#biblio-xhr">[XHR]</a></p>
   <p>The term <dfn data-dfn-type="dfn" data-noexport id="cross-site-scripting">cross-site scripting<a class="self-link" href="#cross-site-scripting"></a></dfn>, or <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="xss">XSS</dfn> for short, refers to
  a content injection attack where an attacker is able to execute malicious code
  in a victim origin. See the <a href="https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)">OWASP page on
  Cross-site Scripting</a> for more information.</p>
   <h3 class="heading settled" data-level="2.1" id="grammar"><span class="secno">2.1. </span><span class="content">Grammatical Concepts</span><a class="self-link" href="#grammar"></a></h3>
    The Augmented Backus-Naur Form (ABNF) notation used in this document is
  specified in RFC5234. <a data-link-type="biblio" href="#biblio-rfc5234">[RFC5234]</a> 
   <p>Lowercase characters, the <code>a-z</code> portion of <a data-link-type="dfn" href="https://tools.ietf.org/html/rfc5234#appendix-B.1" id="ref-for-appendix-B.1">ALPHA</a>, are defined by the grammar:</p>
<pre><dfn class="dfn-paneled" data-dfn-type="grammar" data-export id="grammardef-loweralpha">LOWERALPHA</dfn> = %x61-7A   ; a-z
</pre>
   <h2 class="heading settled" data-level="3" id="defining-suborigin"><span class="secno">3. </span><span class="content">Defining a Suborigin</span><a class="self-link" href="#defining-suborigin"></a></h2>
   <p>Origins are a mechanism for user agents to group URIs into protection domains.
  Two URIs are in the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#same-origin" id="ref-for-same-origin">same-origin</a> if they share
  the same <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-scheme" id="ref-for-concept-scheme">scheme</a>, <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-host" id="ref-for-concept-host">host</a>, and <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-port" id="ref-for-concept-port">port</a>.  If URIs are same-origin,
  then they share the same authority and can access all of each others resources.</p>
   <p>Compared to per-user isolation in traditional operating systems, the
  same-origin policy isolates distinct applications identified by their origins.
  This has been a successful isolation mechanism on the Web.  However, it does
  limit the flexibility of a page to separate itself into a new protection domain
  as it automatically shares authority with all other identical origins. These origins
  are defined by physical, rather than programmatic, properties.  While it is
  possible to setup unique domains and ports for different parts of the same
  application (scheme is more difficult to separate out), there are a diverse set
  of practical problems in doing so.</p>
   <p>Suborigins provide a mechanism for creating this type of separation
  programatically. Any resources may provide, in a manner detailed below, a string
  value <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace">suborigin namespace</a>.  If either of two URIs provide a suborigin
  namespace, then the two URIs are in the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#same-origin" id="ref-for-same-origin①">same-origin</a> if and only if they
  share the same <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-scheme" id="ref-for-concept-scheme①">scheme</a>, <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-host" id="ref-for-concept-host①">host</a>, <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-port" id="ref-for-concept-port①">port</a>, and <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace①">suborigin
  namespace</a>.</p>
   <h3 class="heading settled" data-level="3.1" id="difficulties"><span class="secno">3.1. </span><span class="content">Difficulties using subdomains</span><a class="self-link" href="#difficulties"></a></h3>
   <p><em>This section is not normative.</em></p>
   <p>At first glance, subdomains provide an ability to setup multiple origins and
  isolate applications. Unfortunately, a number of practical difficulties make
  relying on subdomains infeasible.</p>
   <h4 class="heading settled" data-level="3.1.1" id="separate-applications-same-origin"><span class="secno">3.1.1. </span><span class="content">Separate applications, same origin</span><a class="self-link" href="#separate-applications-same-origin"></a></h4>
    Google runs Search and Maps on the same domain, respectively <code>https://www.google.com</code> and <code>https://www.google.com/maps</code>. While these two applications are
  fundamentally separate, there are many reasons for hosting them on the same
  origin, including historical links, branding, and performance.  However, from
  security perspective, this means that a compromise of one application is a
  compromise of the other since the only security boundary in the browser is the
  origin, and both applications run in the same origin.  Thus, even if
  Google Search were to successful implement a strong Content Security Policy <a data-link-type="biblio" href="#biblio-csp2">[CSP2]</a>, if Google Maps were to have an XSS vulnerability, it would be
  equivalent to having an XSS on Google Search as well, negating Google Search’s
  security measures. 
   <h4 class="heading settled" data-level="3.1.2" id="separation-in-single-application"><span class="secno">3.1.2. </span><span class="content">Separation within a single application</span><a class="self-link" href="#separation-in-single-application"></a></h4>
    Separation is sometimes desirable within a single application because of the
  presence of untrusted data. Take, for example, a social networking site with
  many different user profiles. Each profile contains lots of untrusted content
  created by a single user but it’s all hosted on a single origin. In order to
  separate untrusted content, the application might want a way to put all profile
  information into separate logical origins while all being hosted at the same
  physical origin. Furthermore, all content within a profile should be able to
  access all other content within the same origin, even if displayed in unique
  frames. 
   <p>This type of privilege separation within an application has been shown to be
  valuable and reasonable for applications to do by work such as
  Privilege Separation in HTML5 Applications by Akhawe et al <a data-link-type="biblio" href="#biblio-privilegeseparation">[PRIVILEGESEPARATION]</a>. However, these systems rely on cross frame messaging
  using <code>postMessage</code> even for content in the same trust boundary since
  they utilize <code>sandbox</code>. This provides much of the motivation for the
  named container nature of suborigins.</p>
   <h3 class="heading settled" data-level="3.2" id="threat-model"><span class="secno">3.2. </span><span class="content">Threat Model</span><a class="self-link" href="#threat-model"></a></h3>
   <p><a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin">Origins</a> and the <a href="http://www.w3.org/Security/wiki/Same_Origin_Policy">Same-Origin Policy</a> have provided a strong defense against
  malicious applications. Instead of giving the application the power of the user,
  applications on the Web are limited to a unique space that is defined by their
  host. However, by tying the origin to the physical host, this has limited the
  power of developers.</p>
   <p>Suborigins attempt to provide developers with tool to contain two different
  principles that are on the same host. Suborigins allow two or more applications
  or modules to be hosted at the same origin but use the same origin policy to
  separate them from each other.</p>
   <h4 class="heading settled" data-level="3.2.1" id="threat-model-cross-doc"><span class="secno">3.2.1. </span><span class="content">Cross-Document Attacker</span><a class="self-link" href="#threat-model-cross-doc"></a></h4>
   <p>An attacker that is able to compromise one document should not be able to
  control another document that is on the same host but delivered in a different
  suborigin namespace. If an attacker is able to <a data-link-type="dfn" href="#xss" id="ref-for-xss">XSS</a>, for example, a
  document on <code>example.com</code> delivered in the suborigin namespace <code>foo</code>,
  the attacker should not be able to control any document on <code>example.com</code> not in the <code>foo</code> namespace.</p>
   <p class="issue" id="issue-4b8e74eb"><a class="self-link" href="#issue-4b8e74eb"></a> TODO(devd): Should we also assert that attacker on main/parent origin
  cannot compromise the app in sub-origin?</p>
   <p class="issue" id="issue-df2253b2"><a class="self-link" href="#issue-df2253b2"></a> "Should not control" is a stronger statement than I think we want to
  make. The browser can only isolate per origin isolation. If the app has a bug
  (due to postmessage or server-side) the browser can’t do anything. We should
  stick to saying "are isolated like physical origins."</p>
   <h4 class="heading settled" data-level="3.2.2" id="threat-model-out-of-scope"><span class="secno">3.2.2. </span><span class="content">Out of Scope Attacker</span><a class="self-link" href="#threat-model-out-of-scope"></a></h4>
   <p>This tool is purely for modularity and meant to be an application security tool.
  It is <em>not</em> meant to help users differentiate between two different
  applications at the same host, as reflected by the fact that user agents may not
  put the suborigin in user-visible UI. Additionally, suborigins cannot protect
  against colluding malicious or compromised applications.</p>
   <h3 class="heading settled" data-level="3.3" id="suborigins-vs-origins"><span class="secno">3.3. </span><span class="content">Relationship of Suborigins to Origins</span><a class="self-link" href="#suborigins-vs-origins"></a></h3>
   <p>Suborigins, in fact, do not provide any new authority to resources. Suborigins
  simply provide <em>an additional way to construct Origins</em>. That is,
  Suborigins do not supercede Origins or provide any additional authority above
  Origins. From the user agent’s  perspective, two resources in different
  Suborigins are simply in different Origins, and the relationship between the
  two resources should be the same as any other two differing origins as
  described in <a href="https://html.spec.whatwg.org/multipage/origin.html#origin">HTML 5 §7.5 Origin</a> and <a data-link-type="biblio" href="#biblio-rfc6454">[RFC6454]</a>. However, given the
  impracticalities this may impart on some applications who might want to adopt
  Suborigins, a few security-model opt-outs to ease the use of Suborigins in
  legacy applications are also presented. See <a href="#security-model-opt-outs">§ 6.3 Security Model Opt-Outs</a> for
  more information.</p>
   <h3 class="heading settled" data-level="3.4" id="opting-in"><span class="secno">3.4. </span><span class="content">Opting into a Suborigin</span><a class="self-link" href="#opting-in"></a></h3>
   <p>Unlike the <code>sandbox</code> attribute, suborigin namespaces are predictable and
  controllable. Because of this, potentially untrusted content cannot opt into
  suborigins, unlike iframe sandboxes. If they could, then an XSS on a site could
  enter a specific suborigin and access all of its resources, thus violating the
  isolation suborigins intend to provide. To prevent this, the
  server (rather than a resource itself) is the only authoritative
  source of the suborigin namespace of a resource. The server communicates the
  suborigin of a resource to the user agent through a new <code>suborigin</code> header,
  which takes a string value that is the namespace. For example, to put a
  resource in the <code>testing</code> suborigin namespace, the server would specify the
  following HTTP header in the response:</p>
<pre>suborigin: testing
</pre>
   <h3 class="heading settled" data-level="3.5" id="the-suborigin-header"><span class="secno">3.5. </span><span class="content">The <code>suborigin</code> header</span><a class="self-link" href="#the-suborigin-header"></a></h3>
   <p>Suborigins are defined by a <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="suborigin">suborigin</dfn> HTTP response header. The syntax
  for the name and value of the header are described by the following ABNF
  grammar <a data-link-type="biblio" href="#biblio-rfc5234">[RFC5234]</a>:</p>
<pre><dfn class="dfn-paneled" data-dfn-type="grammar" data-export id="grammardef-suborigin-name">suborigin-name</dfn> = <a data-link-type="grammar" href="#grammardef-loweralpha" id="ref-for-grammardef-loweralpha">LOWERALPHA</a> *( <a data-link-type="grammar" href="#grammardef-loweralpha" id="ref-for-grammardef-loweralpha①">LOWERALPHA</a> / <a data-link-type="grammar" href="https://tools.ietf.org/html/rfc5234#appendix-B.1" id="ref-for-appendix-B.1①">DIGIT</a> )
<dfn class="dfn-paneled" data-dfn-type="grammar" data-export id="grammardef-suborigin-policy-option">suborigin-policy-option</dfn> = "'unsafe-postmessage-send'"
                          / "'unsafe-postmessage-receive'"
                          / "'unsafe-cookies'"
                          / "'unsafe-credentials'"
<dfn class="dfn-paneled" data-dfn-type="grammar" data-export id="grammardef-suborigin-policy-list">suborigin-policy-list</dfn> = 1*(<a data-link-type="grammar" href="https://tools.ietf.org/html/rfc7230#section-3.2.3" id="ref-for-section-3.2.3">RWS</a> <a data-link-type="grammar" href="#grammardef-suborigin-policy-option" id="ref-for-grammardef-suborigin-policy-option">suborigin-policy-option</a> <a data-link-type="grammar" href="https://tools.ietf.org/html/rfc7230#section-3.2.3" id="ref-for-section-3.2.3①">OWS</a>)
<dfn data-dfn-type="grammar" data-export id="grammardef-suborigin-header">suborigin-header<a class="self-link" href="#grammardef-suborigin-header"></a></dfn> = <a data-link-type="grammar" href="#grammardef-suborigin-name" id="ref-for-grammardef-suborigin-name">suborigin-name</a> [ <a data-link-type="grammar" href="#grammardef-suborigin-policy-list" id="ref-for-grammardef-suborigin-policy-list">suborigin-policy-list</a> ]
</pre>
   <p>User agents MUST ignore multiple suborigin headers and only apply the first.</p>
   <p>A resource’s <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="suborigin-namespace">suborigin namespace</dfn> is the value of the <a data-link-type="grammar" href="#grammardef-suborigin-name" id="ref-for-grammardef-suborigin-name①">suborigin-name</a> in the <code>suborigin</code> header.</p>
   <p>A resource’s <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="suborigin-policy">suborigin policy</dfn> is the list of individual <a data-link-type="grammar" href="#grammardef-suborigin-policy-option" id="ref-for-grammardef-suborigin-policy-option①">suborigin-policy-option</a> values in the <code>suborigin</code> header’s <a data-link-type="grammar" href="#grammardef-suborigin-policy-list" id="ref-for-grammardef-suborigin-policy-list①">suborigin-policy-list</a>.</p>
   <p class="note" role="note"><span>Note:</span> A suborigin name must start with a lowercase character, but after the
  first character, the name may contain lowercase characters or numerals. This
  is to avoid potential confusion when the origin is serialized if the
  serialization started with a number.</p>
   <h3 class="heading settled" data-level="3.6" id="representation"><span class="secno">3.6. </span><span class="content">Representation of Suborigins</span><a class="self-link" href="#representation"></a></h3>
   <p>At an abstract level, a suborigin consists of the <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin">physical
  origin</a>, which is a <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-scheme" id="ref-for-concept-scheme②">scheme</a>, <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-host" id="ref-for-concept-host②">host</a>, and <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-port" id="ref-for-concept-port②">port</a>, plus a <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace②">suborigin namespace</a>.  However, as mentioned above, suborigins are
  intended to fit within the framework of <a href="https://html.spec.whatwg.org/multipage/origin.html#origin">HTML 5 §7.5 Origin</a> and <a data-link-type="biblio" href="#biblio-rfc6454">[RFC6454]</a>.
  Therefore, this specification provides a way of serializing a Suborigin bound
  resource into a physical origin. This is done by inserting the suborigin
  namespace into the host of the Origin, thus creating a new host but
  maintaining all of the information about both the original scheme, host, port,
  and the suborigin namespace. The serialization format appends the string "-so"
  to the scheme and prepends the host name with the suborigin namespace followed
  by a "." character.</p>
   <p>For example, a resource hosted at <code>https://example.com/</code> in
  the suborigin namespace <code>profile</code> would be serialized as <code>https-so://profile.example.com/</code>.</p>
   <p>Similarly, a resource hosted at <code>https://example.com:8080/</code> in
  the suborigin namespace <code>separate</code> would be serialized as <code>https-so://separate.example.com:8080/</code>.</p>
   <p>Internally, the user agent just tracks the <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace③">suborigin namespace</a> of the resource.
  When the origin needs to be serialized, the user agent should
  follow the algorithm in <a href="#serializing">§ 6.1.6 Serializing Suborigins</a>.</p>
   <p class="issue" id="issue-f67832ce"><a class="self-link" href="#issue-f67832ce"></a> TODO: Determine how the serialization should relate to the URL spec:
  https://url.spec.whatwg.org/#host-parsing</p>
   <h3 class="heading settled" data-level="3.7" id="suborigin-in-js"><span class="secno">3.7. </span><span class="content">Accessing the Suborigin in JavaScript</span><a class="self-link" href="#suborigin-in-js"></a></h3>
   <p>A <code>suborigin</code> property is added to the <a data-link-type="dfn" href="https://dom.spec.whatwg.org/#concept-document" id="ref-for-concept-document">document</a> object which <a data-link-type="dfn" href="https://dom.spec.whatwg.org/#concept-reflect" id="ref-for-concept-reflect">reflects</a> the value of the suborigin namespace for the current execution
  context. If there is no suborigin namespace, the value should be undefined.</p>
   <p>Additionally, the <code>origin</code> property of the <a data-link-type="dfn" href="https://dom.spec.whatwg.org/#concept-document" id="ref-for-concept-document①">document</a> object should reflect
  the serialized value of the origin as returned by <a href="#serializing">§ 6.1.6 Serializing Suborigins</a>.</p>
   <p class="issue" id="issue-1dbd01cb"><a class="self-link" href="#issue-1dbd01cb"></a> TODO(jww): Need to write the formal IDL for this.</p>
   <h2 class="heading settled" data-level="4" id="access-control"><span class="secno">4. </span><span class="content">Access Control</span><a class="self-link" href="#access-control"></a></h2>
   <p>Cross-origin (including cross-suborigin) communication is tricky when suborigins
  are involved because they need to be backwards compatible with user agents that
  do not support suborigins while providing origin-separation for user agents that
  do support suborigins. The following discussions discuss the three major
  cross-origin mechanisms that are relevant: <a data-link-type="dfn" href="#cors" id="ref-for-cors①">CORS</a>, <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage" id="ref-for-dom-messageport-postmessage①"><code>postMessage</code></a>,
  and workers <a data-link-type="biblio" href="#biblio-workers">[WORKERS]</a>.</p>
   <p class="issue" id="issue-4f0009c4"><a class="self-link" href="#issue-4f0009c4"></a> TODO(devd): Making things specific to XHR or CORS is weird. We should
  just make all fetches inside a suborigin CORS fetches and be done with it.</p>
   <h3 class="heading settled" data-level="4.1" id="cors-ac"><span class="secno">4.1. </span><span class="content">CORS</span><a class="self-link" href="#cors-ac"></a></h3>
   <p>For pages in a suborigin namespace, all <a data-link-type="dfn" href="#xmlhttprequest" id="ref-for-xmlhttprequest"><code>XMLHttpRequest</code></a>s and <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#concept-fetch" id="ref-for-concept-fetch"><code>fetch</code></a> requests to any URL should be treated as cross-origin, thus
  triggering a <a data-link-type="dfn" href="https://www.w3.org/TR/cors#cross-origin-request-with-preflight-0" id="ref-for-cross-origin-request-with-preflight-0">cross-origin request with preflight</a> for all non-<a data-link-type="dfn" href="https://www.w3.org/TR/cors#simple-cross-origin-request" id="ref-for-simple-cross-origin-request">simple
  cross-origin requests</a>. Additionally, all requests from a suborigin
  namespace must include a <code>Suborigin</code> header whose value is the context’s
  suborigin name.  Finally, the <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#origin-header" id="ref-for-origin-header"><code>Origin</code> header</a> <a data-link-type="biblio" href="#biblio-fetch">[FETCH]</a> value must use
  the serialized suborigin value instead of the serialized origin, as described
  in <a href="#serializing">§ 6.1.6 Serializing Suborigins</a>.</p>
   <p>Similar changes are needed for responses from the server with the addition of an <code>Access-Control-Allow-Suborigin</code> response header. Its value must match the
  context’s suborigin namespace value, or <code>*</code> to allow all suborigin namespaces.
  At the same time, the <code>Access-Control-Allow-Origin</code> response header value must
  be modified to use the serialized suborigin value instead of the serializied
  origin, as described in <a href="#serializing">§ 6.1.6 Serializing Suborigins</a>.</p>
   <p class="note" role="note"><span>Note:</span> Since the suborigin of a server resource is unknown until fetched, all
  requests, even to resources in the same suborigin are <em>cross-origin</em>.
  Concretely, imagine putting https://example.com/widget/ in the 'widget'
  suborigin. An XmlHttpRequest from /widget/index.html to /widget/data.json
  will be treatd as a cross origin request. A simple XmlHttpRequest will need
  an Access-Control-Allow-Suborigin header allowing the page to read the
  response. An XmlHttpRequest of content-type text/json will be preflighted.</p>
   <p class="issue" id="issue-5b3d4495"><a class="self-link" href="#issue-5b3d4495"></a> TODO(jww): Formal definition of the headers and responses w/grammars.
  Also need to be explicit about <code>*</code> having same limitations as <code>Access-Control-Allow-Origin</code> w/credentials.</p>
   <p class="issue" id="issue-6750573e"><a class="self-link" href="#issue-6750573e"></a> Access-Control-Allow-Origin * fails with credentialed requests. Does
  Access-Control-Allow-Suborigin have the same behavior? We should detail that
  in more detail.</p>
   <p class="issue" id="issue-5be18446"><a class="self-link" href="#issue-5be18446"></a> Browsers have a really low cache time (15mins) for preflight responses
  which makes CORS a big pain for websites. This will become even more salient
  with suborigins. Should the spec ask browsers to increase cache times?</p>
   <p class="issue" id="issue-aedb28e2"><a class="self-link" href="#issue-aedb28e2"></a> Serializing the suborigin value into the origin header seems like it
  will break things. Whats the risk with serializing the physical origin in the
  origin header? The browser won’t let you read the responses (or succeed
  preflight) if neither of them have the right allow-suborigin behavior. This
  seems more compatible with no security risk.</p>
   <h3 class="heading settled" data-level="4.2" id="postmessage-ac"><span class="secno">4.2. </span><span class="content"><code>postMessage</code></span><a class="self-link" href="#postmessage-ac"></a></h3>
   <p>Cross-origin messaging via <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage" id="ref-for-dom-messageport-postmessage②"><code>postMessage</code></a> requires that the recipient be
  able to see the suborigin namespace of the message sender so it can make an
  appropriate access control decision. We introduce a new dictionary <code>ExtendedOrigin</code> that holds information about both the origin and
  the suborigin namespace:</p>
<pre class="idl highlight def"><c- b>dictionary</c-> <dfn class="dfn-paneled idl-code" data-dfn-type="dictionary" data-export id="dictdef-extendedorigin"><code><c- g>ExtendedOrigin</c-></code></dfn> {
  <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString"><c- b>USVString</c-></a> <dfn class="idl-code" data-default="&quot;&quot;" data-dfn-for="ExtendedOrigin" data-dfn-type="dict-member" data-export data-type="USVString " id="dom-extendedorigin-origin"><code><c- g>origin</c-></code><a class="self-link" href="#dom-extendedorigin-origin"></a></dfn> = "";
  <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString①"><c- b>USVString</c-></a>? <dfn class="idl-code" data-default="null" data-dfn-for="ExtendedOrigin" data-dfn-type="dict-member" data-export data-type="USVString? " id="dom-extendedorigin-suborigin"><code><c- g>suborigin</c-></code><a class="self-link" href="#dom-extendedorigin-suborigin"></a></dfn> = <c- b>null</c->;
};
</pre>
   <p class="issue" id="issue-c9cb881f"><a class="self-link" href="#issue-c9cb881f"></a> We’re monkey-patching HTML, submit a PR when we’re sure this is the
  general direction we want to go in.</p>
   <p>And we extend the definition of the MessageEvent and MessageEventInit as follows:</p>
<pre class="idl highlight def"><c- b>interface</c-> <dfn class="idl-code" data-dfn-type="interface" data-export id="messageevent"><code><c- g>MessageEvent</c-></code><a class="self-link" href="#messageevent"></a></dfn> {
  <c- b>readonly</c-> <c- b>attribute</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString②"><c- b>USVString</c-></a>? <dfn class="idl-code" data-dfn-for="MessageEvent" data-dfn-type="attribute" data-export data-readonly data-type="USVString?" id="dom-messageevent-origin"><code><c- g>origin</c-></code><a class="self-link" href="#dom-messageevent-origin"></a></dfn>;
  <c- b>readonly</c-> <c- b>attribute</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin"><c- n>ExtendedOrigin</c-></a> <dfn class="idl-code" data-dfn-for="MessageEvent" data-dfn-type="attribute" data-export data-readonly data-type="ExtendedOrigin" id="dom-messageevent-extendedorigin"><code><c- g>extendedOrigin</c-></code><a class="self-link" href="#dom-messageevent-extendedorigin"></a></dfn>;
  <c- b>void</c-> <dfn class="idl-code" data-dfn-for="MessageEvent" data-dfn-type="method" data-export data-lt="initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports)|initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source)|initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId)|initMessageEvent(type, bubbles, cancelable, data, extendedOrigin)|initMessageEvent(type, bubbles, cancelable, data)|initMessageEvent(type, bubbles, cancelable)|initMessageEvent(type, bubbles)|initMessageEvent(type)" id="dom-messageevent-initmessageevent"><code><c- g>initMessageEvent</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent"></a></dfn>(<a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-DOMString" id="ref-for-idl-DOMString"><c- b>DOMString</c-></a> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-type"><code><c- g>type</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-type"></a></dfn>, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-boolean" id="ref-for-idl-boolean"><c- b>boolean</c-></a> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-bubbles"><code><c- g>bubbles</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-bubbles"></a></dfn> = <c- b>false</c->, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-boolean" id="ref-for-idl-boolean①"><c- b>boolean</c-></a> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-cancelable"><code><c- g>cancelable</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-cancelable"></a></dfn> = <c- b>false</c->, <c- b>optional</c-> <c- b>any</c-> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-data"><code><c- g>data</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-data"></a></dfn> = <c- b>null</c->, <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin①"><c- n>ExtendedOrigin</c-></a>? <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-extendedorigin"><code><c- g>extendedOrigin</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-extendedorigin"></a></dfn> = <c- b>null</c->, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-DOMString" id="ref-for-idl-DOMString①"><c- b>DOMString</c-></a> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-lasteventid"><code><c- g>lastEventId</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-lasteventid"></a></dfn> = "", <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="https://html.spec.whatwg.org/multipage/comms.html#messageeventsource" id="ref-for-messageeventsource"><c- n>MessageEventSource</c-></a>? <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-source"><code><c- g>source</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-source"></a></dfn> = <c- b>null</c->, <c- b>optional</c-> <c- b>sequence</c->&lt;<a class="n" data-link-type="idl-name" href="https://html.spec.whatwg.org/multipage/web-messaging.html#messageport" id="ref-for-messageport"><c- n>MessagePort</c-></a>> <dfn class="idl-code" data-dfn-for="MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId), MessageEvent/initMessageEvent(type, bubbles, cancelable, data, extendedOrigin), MessageEvent/initMessageEvent(type, bubbles, cancelable, data), MessageEvent/initMessageEvent(type, bubbles, cancelable), MessageEvent/initMessageEvent(type, bubbles), MessageEvent/initMessageEvent(type)" data-dfn-type="argument" data-export id="dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-ports"><code><c- g>ports</c-></code><a class="self-link" href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-ports"></a></dfn> = []);
};

<c- b>dictionary</c-> <dfn class="idl-code" data-dfn-type="dictionary" data-export id="dictdef-messageeventinit"><code><c- g>MessageEventInit</c-></code><a class="self-link" href="#dictdef-messageeventinit"></a></dfn> {
  <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin②"><c- n>ExtendedOrigin</c-></a>? <dfn class="idl-code" data-default="null" data-dfn-for="MessageEventInit" data-dfn-type="dict-member" data-export data-type="ExtendedOrigin? " id="dom-messageeventinit-extendedorigin"><code><c- g>extendedOrigin</c-></code><a class="self-link" href="#dom-messageeventinit-extendedorigin"></a></dfn> = <c- b>null</c->;
};
</pre>
   <p>Similarly, we add a new overloaded version of postMessage to the Window interface:</p>
<pre class="idl highlight def"><c- b>partial</c-> <c- b>interface</c-> <a class="idl-code" data-link-type="interface" href="https://html.spec.whatwg.org/multipage/window-object.html#window" id="ref-for-window"><c- g>Window</c-></a> {
  <c- b>void</c-> <dfn class="idl-code" data-dfn-for="Window" data-dfn-type="method" data-export data-lt="postMessage(message, targetOrigin, transfer)|postMessage(message, targetOrigin)|postMessage(message)" id="dom-window-postmessage"><code><c- g>postMessage</c-></code><a class="self-link" href="#dom-window-postmessage"></a></dfn>(<c- b>any</c-> <dfn class="idl-code" data-dfn-for="Window/postMessage(message, targetOrigin, transfer), Window/postMessage(message, targetOrigin), Window/postMessage(message)" data-dfn-type="argument" data-export id="dom-window-postmessage-message-targetorigin-transfer-message"><code><c- g>message</c-></code><a class="self-link" href="#dom-window-postmessage-message-targetorigin-transfer-message"></a></dfn>, <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin③"><c- n>ExtendedOrigin</c-></a> <dfn class="idl-code" data-dfn-for="Window/postMessage(message, targetOrigin, transfer), Window/postMessage(message, targetOrigin), Window/postMessage(message)" data-dfn-type="argument" data-export id="dom-window-postmessage-message-targetorigin-transfer-targetorigin"><code><c- g>targetOrigin</c-></code><a class="self-link" href="#dom-window-postmessage-message-targetorigin-transfer-targetorigin"></a></dfn>, <c- b>optional</c-> <c- b>sequence</c->&lt;<a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-object" id="ref-for-idl-object"><c- b>object</c-></a>> <dfn class="idl-code" data-dfn-for="Window/postMessage(message, targetOrigin, transfer), Window/postMessage(message, targetOrigin), Window/postMessage(message)" data-dfn-type="argument" data-export id="dom-window-postmessage-message-targetorigin-transfer-transfer"><code><c- g>transfer</c-></code><a class="self-link" href="#dom-window-postmessage-message-targetorigin-transfer-transfer"></a></dfn> = []);
};
</pre>
   <p>Those new interfaces can also be used to communicate with browsing contexts
  that aren’t in a suborigin namespace. Furthermore, the <code>origin</code> attribute of
  an <code>MessageEvent</code> will be <code>null</code> (the value, not the string) if the <code>suborigin</code> attribute of the event’s <code>extendedOrigin</code> is non-<code>null</code>, unless
  either <code>unsafe-postmessage-receive</code> or <code>unsafe-postmessage-send</code> was
  specified (depending on whether the context inside the suborigin, or its
  communication peers don’t support this API).</p>
   <p>If the <code>suborigin</code> attribute of the <code>EventInitializer</code> passed to <code>postMessage</code> is the literal string <code>*</code>, it will match any suborigin
  namespace, including if the receiver doesn’t have any suborigin. Otherwise,
  the suborigin has to match exactly. A browsing context that doesn’t specify a
  suborigin is matched by the value <code>null</code>, and not by the empty string. Again,
  the restriction that a suborigin namespace is required can be removed via the <code>unsafe-postmessage-receive</code> and <code>unsafe-postmessage-send</code> options.</p>
   <p class="example" id="example-f411dc24"><a class="self-link" href="#example-f411dc24"></a> Website authors can use the presence of the EventInitializer constructor to
    feature detect the presence of these new interfaces. For <code>postMessage</code> and <code>initMessageEvent</code>, authors can also add a custom <code>toString</code> method to the
    dictionary they pass to it like so: </p>
<pre>postMessage(data, {
    'origin': 'http://example.com',
    'suborigin': '*',
    'toString': () => { return 'http://example.com' }
});
</pre>
   <p></p>
   <p class="issue" id="issue-ebe2c3d2"><a class="self-link" href="#issue-ebe2c3d2"></a> TODO(jww): Formalize by updating the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage" id="ref-for-dom-messageport-postmessage③">postMessage</a> algorithm</p>
   <h3 class="heading settled" data-level="4.3" id="workers-ac"><span class="secno">4.3. </span><span class="content">Workers</span><a class="self-link" href="#workers-ac"></a></h3>
   <p>User agents MUST refuse to create or execute any workers in a page executing in
  a sub-origin.</p>
   <p class="issue" id="issue-3fffd8fc"><a class="self-link" href="#issue-3fffd8fc"></a> TODO: Formalize. Not sure what this will look like yet. Chrome and
  Opera don’t allow creation of workers from sandbox’d iframes/the 'null'
  origin, but not sure if this formalized in a spec. If it is, should probably
  just update whatever disallows creation from sandbox.</p>
   <p class="note" role="note"><span>Note:</span> This may change in the future, and suborigins may eventually be allowed to
  register service workers, but, for now, allowing the creation of any workers,
  including service workers and shared workers, from suborigins adds too many
  complications. Applications can still create workers by creating an iframe of
  a page not in a suborigin.</p>
   <h2 class="heading settled" data-level="5" id="impact"><span class="secno">5. </span><span class="content">Impact on Web Platform</span><a class="self-link" href="#impact"></a></h2>
   <p>Content inside a suborigin namespace is restricted in the same way that other
  origins are restricted. There are some additional restrictions as well, in
  order to simplify some complicated cases.</p>
   <h3 class="heading settled" data-level="5.1" id="storage"><span class="secno">5.1. </span><span class="content">Storage</span><a class="self-link" href="#storage"></a></h3>
   <p>The storage APIs, such as <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage" id="ref-for-dom-localstorage">localStorage</a></code> and <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage" id="ref-for-dom-sessionstorage">sessionStorage</a></code>, are
  accessible from within suborigins. By nature of their APIs, they are bound to
  the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin①">origin</a> of the <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document">Document</a></code>, which has the practical effect of
  giving a separate <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#storage-2" id="ref-for-storage-2">Storage</a></code> object to each <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace④">suborigin namespace</a>. Per
  the definitions in <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage" id="ref-for-dom-localstorage①">localStorage</a></code> and <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage" id="ref-for-dom-sessionstorage①">sessionStorage</a></code>, the user agent
  MUST provide separate <code class="idl"><a data-link-type="idl" href="https://html.spec.whatwg.org/multipage/webstorage.html#storage-2" id="ref-for-storage-2①">Storage</a></code> objects per <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin②">origin</a>, and thus per <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace⑤">suborigin namespace</a>.</p>
   <h3 class="heading settled" data-level="5.2" id="document-domain"><span class="secno">5.2. </span><span class="content"><code>document.domain</code></span><a class="self-link" href="#document-domain"></a></h3>
   <p>The <code class="idl"><a data-link-type="idl">document.domain</a></code> property
  User agents MUST ignore modifications to the document.domain property of the
  page.</p>
   <h3 class="heading settled" data-level="5.3" id="websockets"><span class="secno">5.3. </span><span class="content">WebSockets</span><a class="self-link" href="#websockets"></a></h3>
   <p>The <a href="https://www.w3.org/TR/websockets/#the-websocket-interface"><code>WebSocket()</code> constructor algrithm</a> <a data-link-type="biblio" href="#biblio-websockets">[WebSockets]</a> is modified as follows:</p>
   <p>After  the current step 1, perform the following step:</p>
   <ol start="2">
    <li data-md>
     <p>If the <a href="https://www.w3.org/TR/html51/webappapis.html#environment-settings-object">origin property</a> of the <em>client</em>’s <a href="https://www.w3.org/TR/html51/webappapis.html#relevant-settings-object">relevant settings object</a> has a <a data-link-type="dfn" href="#suborigin" id="ref-for-suborigin">suborigin</a>, throw a <a href="https://www.w3.org/TR/WebIDL-1/#h-idl-domexception-error-names">SecurityError exception</a>.</p>
   </ol>
   <p class="note" role="note"><span>Note:</span> Suborigins are likely to allow WebSockets in the future, but are
  disabled until it can be decided how they should be protected.</p>
   <h2 class="heading settled" data-level="6" id="framework"><span class="secno">6. </span><span class="content">Framework</span><a class="self-link" href="#framework"></a></h2>
   <p class="note" role="note"><span>Note:</span> These sections are tricky because, unlike physical origins, we can’t
  define suborigins in terms of URIs. Since the suborigin namespace is defined in
  a header, not in the URI, we need to define them in terms of resources.</p>
   <h3 class="heading settled" data-level="6.1" id="origin-updates"><span class="secno">6.1. </span><span class="content">Updates to Origin</span><a class="self-link" href="#origin-updates"></a></h3>
   <p>Suborigins extends the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin③">origin</a> concept. The following sections define
  how this extension works.</p>
   <h4 class="heading settled" data-level="6.1.1" id="suborigin-of-response"><span class="secno">6.1.1. </span><span class="content">Suborigin of a Response</span><a class="self-link" href="#suborigin-of-response"></a></h4>
   <p>TODO: This needs update Fetch to change the origin of response. Maybe just
  need to make sure that response’s URL has the suborigin serialized?a
  https://fetch.spec.whatwg.org/#responses</p>
   <h4 class="heading settled" data-level="6.1.2" id="origin-tuple"><span class="secno">6.1.2. </span><span class="content">Origin Tuple</span><a class="self-link" href="#origin-tuple"></a></h4>
   <p>Update the definition of <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin-tuple" id="ref-for-concept-origin-tuple">tuple origin</a> in the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin④">origin</a> section of <a data-link-type="biblio" href="#biblio-html">[HTML]</a> to read:</p>
   <p>A tuple consists of:</p>
   <ul>
    <li data-md>
     <p>A scheme (a <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-scheme" id="ref-for-concept-scheme③">scheme</a>).</p>
    <li data-md>
     <p>A host (a <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-host" id="ref-for-concept-host③">host</a>).</p>
    <li data-md>
     <p>A port (a <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-port" id="ref-for-concept-port③">port</a>).</p>
    <li data-md>
     <p>A domain (null or a <a data-link-type="dfn" href="https://url.spec.whatwg.org/#concept-domain" id="ref-for-concept-domain">domain</a>). Null unless stated otherwise.</p>
    <li data-md>
     <p>A suborigin (a <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace⑥">suborigin namespace</a>). The empty string unless stated
otherwise.</p>
   </ul>
   <h4 class="heading settled" data-level="6.1.3" id="physical-origin-concept"><span class="secno">6.1.3. </span><span class="content">Physical Origin</span><a class="self-link" href="#physical-origin-concept"></a></h4>
    The <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="physical-origin">physical origin</dfn> of an <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin" id="ref-for-concept-origin⑤">origin</a> is an <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#concept-origin-tuple" id="ref-for-concept-origin-tuple①">origin tuple</a> where the components are: 
   <ul>
    <li data-md>
     <p>The scheme is the scheme component of the origin</p>
    <li data-md>
     <p>The host is the host component of the origin</p>
    <li data-md>
     <p>The port is the port component of the origin</p>
    <li data-md>
     <p>The domain is the domain component of the origin</p>
    <li data-md>
     <p>The suborigin is the empty string</p>
   </ul>
   <h4 class="heading settled" data-level="6.1.4" id="comparing-origins"><span class="secno">6.1.4. </span><span class="content">Comparing Origins</span><a class="self-link" href="#comparing-origins"></a></h4>
   <p>Update the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/origin.html#same-origin" id="ref-for-same-origin②">same origin</a> algorithm in <a data-link-type="biblio" href="#biblio-html">[HTML]</a> such that step 2 reads:</p>
   <ol start="2">
    <li data-md>
     <p>If A and B are both tuple origins and their schemes, hosts, ports, and
 suborigins are identical, then return true.</p>
   </ol>
   <h4 class="heading settled" data-level="6.1.5" id="comparing-physical-origins"><span class="secno">6.1.5. </span><span class="content">Comparing Physical Origins</span><a class="self-link" href="#comparing-physical-origins"></a></h4>
   <p>Two origins, A and B, are said to be <dfn class="dfn-paneled" data-dfn-type="dfn" data-noexport id="same-physical-origin">same physical origin</dfn> if the
  following algorithm returns true:</p>
   <ol>
    <li data-md>
     <p>Let AP be the <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin①">physical origin</a> of A. Let BP be the <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin②">physical
 origin</a> of B.</p>
    <li data-md>
     <p>If AP and BP are the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/origin.html#same-origin" id="ref-for-same-origin③">same origin</a>, return true.</p>
    <li data-md>
     <p>Return false.</p>
   </ol>
   <h4 class="heading settled" data-level="6.1.6" id="serializing"><span class="secno">6.1.6. </span><span class="content">Serializing Suborigins</span><a class="self-link" href="#serializing"></a></h4>
   <p>This section defines how to serialize an origin to a Unicode <a data-link-type="biblio" href="#biblio-unicode6">[Unicode6]</a> string and to an ASCII <a data-link-type="biblio" href="#biblio-rfc0020">[RFC0020]</a> string.</p>
   <h5 class="heading settled" data-level="6.1.6.1" id="unicode-serialization"><span class="secno">6.1.6.1. </span><span class="content">Unicode Serialization of a Suborigin</span><a class="self-link" href="#unicode-serialization"></a></h5>
   <p>Update the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#unicode-serialisation-of-an-origin" id="ref-for-unicode-serialisation-of-an-origin">Unicode serialization of an origin</a> in <a data-link-type="biblio" href="#biblio-html">[HTML]</a> by modifying
  step 4 to read:</p>
   <ol start="4">
    <li data-md>
     <p>Let unicodeOrigin be a new tuple origin consisting origin’s scheme,
 unicodeHost, origin’s port, and origin’s suborigin.</p>
   </ol>
   <h5 class="heading settled" data-level="6.1.6.2" id="ascii-serialization"><span class="secno">6.1.6.2. </span><span class="content">ASCII Serialization of a Suborigin</span><a class="self-link" href="#ascii-serialization"></a></h5>
   <p>Update the steps of <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#ascii-serialisation-of-an-origin" id="ref-for-ascii-serialisation-of-an-origin">ASCII serialization of an origin</a> in <a data-link-type="biblio" href="#biblio-html">[HTML]</a> to
  read:</p>
   <ol>
    <li data-md>
     <p>If origin is an opaque origin, then return "null".</p>
    <li data-md>
     <p>Otherwise, let result be origin’s scheme.</p>
    <li data-md>
     <p>Let <code>schemeSuffix</code> be "-so://" if the suborigin component of origin is not
 the empty string, and "://" otherwise.</p>
    <li data-md>
     <p>Let <code>hostPrefix</code> be the suborigin component of origin with "." appended to
 it if the suborigin component of origin is not the empty string, and ""
 otherwise.</p>
    <li data-md>
     <p>Append <code>schemeSuffix</code> to result.</p>
    <li data-md>
     <p>Append <code>hostPrefix</code> to result.</p>
    <li data-md>
     <p>Append origin’s host, serialized, to result.</p>
    <li data-md>
     <p>If origin’s port is non-null, append a U+003A COLON character (:), and
 origin’s port, serialized, to result.</p>
    <li data-md>
     <p>Return result.</p>
   </ol>
   <h5 class="heading settled" data-level="6.1.6.3" id="document-origin"><span class="secno">6.1.6.3. </span><span class="content"><code>Document</code> object’s origin</span><a class="self-link" href="#document-origin"></a></h5>
   <p>TODO: Need to assign how Document gets a suborigin. Need to patch the "For
  Document objects" subsection of https://html.spec.whatwg.org/#origin. Will
  also probably need to update https://fetch.spec.whatwg.org/#concept-response
  to have a suborigin property, which uses that response to assign a suborigin
  to the origin tuple for Object, similar to
  https://w3c.github.io/webappsec-csp/#sandbox-init.</p>
   <h3 class="heading settled" data-level="6.2" id="dom-interactions"><span class="secno">6.2. </span><span class="content">Interactions with the DOM</span><a class="self-link" href="#dom-interactions"></a></h3>
   <h4 class="heading settled" data-level="6.2.1" id="cookies"><span class="secno">6.2.1. </span><span class="content">Cookies</span><a class="self-link" href="#cookies"></a></h4>
   <p>Append the following to the list of conditions of <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document①">Document</a></code> objects that are <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse">cookie-averse</a> in Section 3.1.2 of HTML5’s <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#resource-metadata-management" id="ref-for-resource-metadata-management">resource metadata
  management</a>:</p>
   <ul>
    <li data-md>
     <p>A <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document②">Document</a></code> who has a non-empty <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace⑦">suborigin namespace</a>, unless the <a data-link-type="grammar" href="#grammardef-suborigin-policy-option" id="ref-for-grammardef-suborigin-policy-option②">suborigin-policy-option</a> for the <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document③">Document</a></code>'s <a data-link-type="dfn" href="#suborigin-policy" id="ref-for-suborigin-policy">suborigin policy</a> contains the <a href="#unsafe-cookies">§ 6.3.3 'unsafe-cookies'</a> value.</p>
   </ul>
   <p>Modify the paragraph following this list to read "scheme/host/port/suborigin
  tuple" instead of "scheme/host/port tuple".</p>
   <p>Additionally, modify step 1 of <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-set-cookie" id="ref-for-attr-meta-http-equiv-set-cookie">Cookie setter</a> to read:</p>
   <ol>
    <li data-md>
     <p>If the meta element has no content attribute, or if that attribute’s value
 is the empty string, or if the <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document④">Document</a></code> is <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse①">cookie-averse</a> then
 abort these steps.</p>
   </ol>
   <p class="note" role="note"><span>Note:</span> A <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse②">cookie-averse</a> <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document⑤">Document</a></code> object has the property that direct
  access to <code>document.cookie</code> returns the empty string, and assigning to <code>document.cookie</code> has no effect whatsoever. However, that network cookies are
  not affected and documents with different <a data-link-type="dfn" href="#suborigin-namespace" id="ref-for-suborigin-namespace⑧">suborigin namespaces</a> on the
  same <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin③">physical origin</a> share the same cookies on the network.</p>
   <p class="note" role="note"><span>Note:</span> For practical purposes, this means that a developer cannot use <code>document.cookie</code> directly because assignment and reading of the object are both
  no-ops. However, a <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse③">cookie-averse</a> <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document⑥">Document</a></code> may
  still use getters and setters on the <code>cookie</code> property of the <code>document</code> object
  and, in that way, may still simulate cookie access.</p>
   <p class="issue" id="issue-90521f50"><a class="self-link" href="#issue-90521f50"></a> Currently, some browsers do not let applications redefine getters and
  setters on cookie averse documents. Should the spec enforce that this is
  allowed?</p>
   <h3 class="heading settled" data-level="6.3" id="security-model-opt-outs"><span class="secno">6.3. </span><span class="content">Security Model Opt-Outs</span><a class="self-link" href="#security-model-opt-outs"></a></h3>
   <p>For backwards compatibility, Suborigins provide several opt-opts from the
  standard security model. A developer can choose to use these opt-outs by
  specifying a <a data-link-type="dfn" href="#suborigin-policy" id="ref-for-suborigin-policy①">suborigin policy</a> in <a href="#the-suborigin-header">the
  suborigin header</a></p>
   <p>Since these opt-outs weaken the security model of suborigins, developers SHOULD
  NOT use these options unless they are required to make their application work.</p>
   <p>The values of <a data-link-type="grammar" href="#grammardef-suborigin-policy-option" id="ref-for-grammardef-suborigin-policy-option③">suborigin-policy-option</a> that may be
  present in a <a data-link-type="dfn" href="#suborigin-policy" id="ref-for-suborigin-policy②">suborigin policy</a> have the following effects:</p>
   <h4 class="heading settled" data-level="6.3.1" id="unsafe-postmessage-receive"><span class="secno">6.3.1. </span><span class="content"><code>'unsafe-postmessage-receive'</code></span><a class="self-link" href="#unsafe-postmessage-receive"></a></h4>
    If <code>unsafe-postmessage-receive</code> is set, <code>MessageEvent</code>s sent to
  browsing context in the respective suborigin namespace will expose the
  serialization of their physical origin via the <code>origin</code> attribute of the <code>MessageEvent</code>s. Browsing context sending <code>MessageEvent</code>s to the suborigin
  do not need to specify a target suborigin. 
   <h4 class="heading settled" data-level="6.3.2" id="unsafe-postmessage-send"><span class="secno">6.3.2. </span><span class="content"><code>'unsafe-postmessage-send'</code></span><a class="self-link" href="#unsafe-postmessage-send"></a></h4>
    If <code>unsafe-postmessage-send</code> is set, the legacy <code>postMessage</code> method can
  be used to communicate from within the browsing context in the respective
  suborigin. The <code>MessageEvent</code>s dispatched in response to a <code>postMessage</code> from
  the respective suborigin will expose the serializatoin of the suborigin’s
  physical origin via the <code>origin</code> attribute. 
   <h4 class="heading settled" data-level="6.3.3" id="unsafe-cookies"><span class="secno">6.3.3. </span><span class="content"><code>'unsafe-cookies'</code></span><a class="self-link" href="#unsafe-cookies"></a></h4>
    Normally, a <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document⑦">Document</a></code> with a non-empty suborigin namespace is <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse④">cookie-averse</a>, which means that cookies cannot be read or written.
  However, if the <a data-link-type="dfn" href="#suborigin-policy" id="ref-for-suborigin-policy③">suborigin policy</a> contains the <code>unsafe-cookies</code> option,
  the <code class="idl"><a data-link-type="idl" href="https://dom.spec.whatwg.org/#document" id="ref-for-document⑧">Document</a></code> is <em>not</em> made <a data-link-type="dfn" href="http://www.w3.org/TR/html51/dom.html#cookie-averse" id="ref-for-cookie-averse⑤">cookie-averse</a>, which leaves
  cookies readable and writable by the execution context. See <a href="#cookies">§ 6.2.1 Cookies</a> for
  the precise definition of how this is defined. 
   <p>Practically speaking, this means that code executing in this suborigin can
  access and set cookies for any other suborigin at that <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin④">physical origin</a>,
  including the empty suborigin. Thus, this option SHOULD NOT be used if cookies
  are security-sensitive in your application.</p>
   <p class="note" role="note"><span>Note:</span> This option is intended only for easing deployment. Application authors
  should carefully evaluate the risk and impact on their application before
  turning it on. The untrusted sub-origin code can overwrite session cookies
  and execute a session fixation attack on the applications running in the
  physical origin. Worse, if an application on the physical origin relies on
  simple double-submit CSRF tokens (not tied to the session), then an untrusted
  sub-origin can execute arbitrary CSRF attacks. Similarly, if session ccookies
  or CSRF cookies are readable from javascript (i.e., they are not Http-Only),
  then the untrusted sub-origin can steal the user’s session or execute
  arbitrary CSRF attacks.</p>
   <h4 class="heading settled" data-level="6.3.4" id="unsafe-credentials"><span class="secno">6.3.4. </span><span class="content"><code>'unsafe-credentials'</code></span><a class="self-link" href="#unsafe-credentials"></a></h4>
   <p>All cross-origin requests  to the <a data-link-type="dfn" href="#physical-origin" id="ref-for-physical-origin⑤">physical origin</a> for the execution
  context will include <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#credentials" id="ref-for-credentials">credentials</a> if the <code>'unsafe-credentials'</code> suborigin policy option for the execution context is set.</p>
   <p>Specifically, update the step 2 of <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#http-network-or-cache-fetch" id="ref-for-http-network-or-cache-fetch">HTTP-network-or-cache fetch</a> in the
  Fetch spec <a data-link-type="biblio" href="#biblio-fetch">[FETCH]</a> to read:</p>
   <ol start="2">
    <li data-md>
     <p>Let credentials flag be set if one of</p>
     <ul>
      <li data-md>
       <p><code>request</code>'s credentials mode is "include"</p>
      <li data-md>
       <p><code>request</code>'s credentials mode is "same-origin" and request’s response
 tainting is "basic"</p>
      <li data-md>
       <p><code>request</code>'s credentials mode is "same-origin" and <code>request</code>'s <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#environment-settings-object" id="ref-for-environment-settings-object">environment settings object</a> has the <code>suborigin unsafe credentials</code> flag set and the request’s <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#concept-request-current-url" id="ref-for-concept-request-current-url">current url</a> is <a data-link-type="dfn" href="#same-physical-origin" id="ref-for-same-physical-origin">same physical origin</a> with <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#concept-request-origin" id="ref-for-concept-request-origin">request origin</a>.</p>
     </ul>
   </ol>
   <p class="note" role="note"><span>Note:</span> This has several important, practical effects. If the <a data-link-type="dfn" href="https://fetch.spec.whatwg.org#concept-request-credentials-mode" id="ref-for-concept-request-credentials-mode">credentials
  mode</a> of a <code>fetch()</code> is set to "same-origin", and if it is to the same
  physical origin as the current execution context, credentials will be
  included. This means that if the <code>crossorigin</code> attribute on elements such
  as <code>&lt;img></code> are set to <code>anonymous</code>, credentials will be sent if the origin
  of the URL is the same physical origin. Similarly, if making an <a data-link-type="dfn" href="#xmlhttprequest" id="ref-for-xmlhttprequest①">XMLHttpRequest</a>, setting this flag is equivalent to setting <a data-link-type="dfn" href="https://xhr.spec.whatwg.org/#the-withcredentials-attribute" id="ref-for-the-withcredentials-attribute"><code>withCredentials</code></a> to <code>true</code> for requests to the same physical
  origin. This means that it credentials will be sent even for requests to
  another suborigin at the same physical origin.</p>
   <p class="issue" id="issue-ec925137"><a class="self-link" href="#issue-ec925137"></a> TODO(jww,aaj): Provide an example of why this might be needed.</p>
   <p class="issue" id="issue-9b7d04a5"><a class="self-link" href="#issue-9b7d04a5"></a> TODO: These opt-out descriptions should probably be moved to the
  individual sections where the behaviors are discussed (i.e. postMessage and
  cookies). These just need to be fleshed out anyway, and examples and reasons
  need to be given. Also, they need to update the processing model, such as
  adding appropriate flags to the environment settings object.</p>
   <h2 class="heading settled" data-level="7" id="practical-considerations"><span class="secno">7. </span><span class="content">Practical Considerations in Using Suborigins</span><a class="self-link" href="#practical-considerations"></a></h2>
   <p>Using suborigins with a Web application should be relatively simple. At the most
  basic level, if you have an application hosted on <code>https://example.com/app/</code>,
  and all of its resources are hosted at subpaths of <code>/app</code>, it requires that the
  server set a Content Security Policy on all HTTP requests to subpaths of <code>/app</code> that contain the header <code>suborigin: namespace</code>, where <code>namespace</code> is of the
  application’s choosing. This will ensure that the user agent loads all of these
  resources into the suborigin <code>namespace</code> and will enforce this boundary
  accordingly.</p>
   <p>Additionally, if your application allows cross-origin requests, instead of
  adding the usual <code>Access-Control-Allow-Origin</code> header for cross-origin requests,
  add <code>Access-Control-Allow-Suborigin</code> headers, as defined in <a href="#cors-ac">§ 4.1 CORS</a>.</p>
   <p>In the client-side portion of the application, if <code>postMessage</code> is used, the
  application must be modified so it does not check the <code>event.origin</code> field.
  Instead, it the <code>event.suborigin</code> fields, as they are defined in <a href="#postmessage-ac">§ 4.2 postMessage</a>.</p>
   <p class="issue" id="issue-810c1065"><a class="self-link" href="#issue-810c1065"></a> TODO(devd): Flesh out the above and make sure it covers all it needs to
  cover.</p>
   <h2 class="heading settled" data-level="8" id="security-considerations"><span class="secno">8. </span><span class="content">Security Considerations</span><a class="self-link" href="#security-considerations"></a></h2>
   <h3 class="heading settled" data-level="8.1" id="presentation-to-users"><span class="secno">8.1. </span><span class="content">Presentation of Suborigins to Users</span><a class="self-link" href="#presentation-to-users"></a></h3>
   <p>A complication of suborigins is that while they provide a meaningful security
  for an application, that boundary makes much less sense to a user. That is,
  physical origins provide a security boundary at a physical level: separate
  scheme, hosts, and ports map to real boundaries external of a given application.
  However, suborigins as a boundary only makes sense <em>within the context of the
  program logic itself</em>, and there is no meaningful way for users to make
  decisions based on suborigins a priori.</p>
   <p>Therefore, suborigins should be used only internally in a user agent and MUST
  NOT be presented to users at all. For example, user agents must never present
  suborigins in link text or a URL bar.</p>
   <p class="issue" id="issue-d4f11cd7"><a class="self-link" href="#issue-d4f11cd7"></a> Is history.pushState allowed in a suborigin? I suggest no to reduce
  complexity and inherit from sandbox behavior. On the other hand, this impacts
  compatibility.</p>
   <h3 class="heading settled" data-level="8.2" id="not-overthrowing-sop"><span class="secno">8.2. </span><span class="content">Not Overthrowing Same-Origin Policy</span><a class="self-link" href="#not-overthrowing-sop"></a></h3>
   <p>Suborigins do not fundamentally change how the same-origin policy works. An
  application without suborigins should work identically to how it always has, and
  even in an application with suborigins, the same-origin policy still applies as
  always. In fact, this document defines suborigins within the context of the
  same-origin policy so that, in theory, serialized suborigins can be thought of
  as a just a special case of the traditional same-origin policy.</p>
   <h3 class="heading settled" data-level="8.3" id="serialization-concerns"><span class="secno">8.3. </span><span class="content">Problems with Serialized Representation</span><a class="self-link" href="#serialization-concerns"></a></h3>
   <p class="issue" id="issue-d8492fe3"><a class="self-link" href="#issue-d8492fe3"></a> TODO: Need to list concerns with serialization, e.g. apps that don’t
  recognize the suborigin serialization, esp. if they blocklist origins.</p>
   <h2 class="heading settled" data-level="9" id="privacy-considerations"><span class="secno">9. </span><span class="content">Privacy Considerations</span><a class="self-link" href="#privacy-considerations"></a></h2>
   <p class="issue" id="issue-747044d5"><a class="self-link" href="#issue-747044d5"></a> TODO: Do we have privacy issues?</p>
  </main>
  <h2 class="no-ref no-num heading settled" id="conformance"><span class="content">Conformance</span><a class="self-link" href="#conformance"></a></h2>
  <h3 class="no-ref no-num heading settled" id="conventions"><span class="content">Document conventions</span><a class="self-link" href="#conventions"></a></h3>
  <p>Conformance requirements are expressed with a combination of
    descriptive assertions and RFC 2119 terminology. The key words “MUST”,
    “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
    “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this
    document are to be interpreted as described in RFC 2119.
    However, for readability, these words do not appear in all uppercase
    letters in this specification. </p>
  <p>All of the text of this specification is normative except sections
    explicitly marked as non-normative, examples, and notes. <a data-link-type="biblio" href="#biblio-rfc2119">[RFC2119]</a></p>
  <p>Examples in this specification are introduced with the words “for example”
    or are set apart from the normative text with <code>class="example"</code>,
    like this: </p>
  <div class="example" id="example-ae2b6bc0">
   <a class="self-link" href="#example-ae2b6bc0"></a> 
   <p>This is an example of an informative example.</p>
  </div>
  <p>Informative notes begin with the word “Note” and are set apart from the
    normative text with <code>class="note"</code>, like this: </p>
  <p class="note" role="note">Note, this is an informative note.</p>
  <h3 class="no-ref no-num heading settled" id="conformant-algorithms"><span class="content">Conformant Algorithms</span><a class="self-link" href="#conformant-algorithms"></a></h3>
  <p>Requirements phrased in the imperative as part of algorithms (such as
    "strip any leading space characters" or "return false and abort these
    steps") are to be interpreted with the meaning of the key word ("must",
    "should", "may", etc) used in introducing the algorithm.</p>
  <p>Conformance requirements phrased as algorithms or specific steps can be
    implemented in any manner, so long as the end result is equivalent. In
    particular, the algorithms defined in this specification are intended to
    be easy to understand and are not intended to be performant. Implementers
    are encouraged to optimize.</p>
<script src="https://www.w3.org/scripts/TR/2016/fixup.js"></script>
  <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index</span><a class="self-link" href="#index"></a></h2>
  <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="content">Terms defined by this specification</span><a class="self-link" href="#index-defined-here"></a></h3>
  <ul class="index">
   <li><a href="#cors">CORS</a><span>, in §2</span>
   <li><a href="#cross-origin-resource-sharing">Cross-Origin Resource Sharing</a><span>, in §2</span>
   <li><a href="#cross-site-scripting">cross-site scripting</a><span>, in §2</span>
   <li><a href="#dictdef-extendedorigin">ExtendedOrigin</a><span>, in §4.2</span>
   <li>
    extendedOrigin
    <ul>
     <li><a href="#dom-messageevent-extendedorigin">attribute for MessageEvent</a><span>, in §4.2</span>
     <li><a href="#dom-messageeventinit-extendedorigin">dict-member for MessageEventInit</a><span>, in §4.2</span>
    </ul>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable, data)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable, data, extendedOrigin)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source)</a><span>, in §4.2</span>
   <li><a href="#dom-messageevent-initmessageevent">initMessageEvent(type, bubbles, cancelable, data, extendedOrigin, lastEventId, source, ports)</a><span>, in §4.2</span>
   <li><a href="#grammardef-loweralpha">LOWERALPHA</a><span>, in §2.1</span>
   <li><a href="#messageevent">MessageEvent</a><span>, in §4.2</span>
   <li><a href="#dictdef-messageeventinit">MessageEventInit</a><span>, in §4.2</span>
   <li>
    origin
    <ul>
     <li><a href="#dom-messageevent-origin">attribute for MessageEvent</a><span>, in §4.2</span>
     <li><a href="#dom-extendedorigin-origin">dict-member for ExtendedOrigin</a><span>, in §4.2</span>
    </ul>
   <li><a href="#physical-origin">physical origin</a><span>, in §6.1.3</span>
   <li><a href="#dom-window-postmessage">postMessage(message)</a><span>, in §4.2</span>
   <li><a href="#dom-window-postmessage">postMessage(message, targetOrigin)</a><span>, in §4.2</span>
   <li><a href="#dom-window-postmessage">postMessage(message, targetOrigin, transfer)</a><span>, in §4.2</span>
   <li><a href="#same-physical-origin">same physical origin</a><span>, in §6.1.5</span>
   <li>
    suborigin
    <ul>
     <li><a href="#suborigin">definition of</a><span>, in §3.5</span>
     <li><a href="#dom-extendedorigin-suborigin">dict-member for ExtendedOrigin</a><span>, in §4.2</span>
    </ul>
   <li><a href="#grammardef-suborigin-header">suborigin-header</a><span>, in §3.5</span>
   <li><a href="#grammardef-suborigin-name">suborigin-name</a><span>, in §3.5</span>
   <li><a href="#suborigin-namespace">suborigin namespace</a><span>, in §3.5</span>
   <li><a href="#suborigin-policy">suborigin policy</a><span>, in §3.5</span>
   <li><a href="#grammardef-suborigin-policy-list">suborigin-policy-list</a><span>, in §3.5</span>
   <li><a href="#grammardef-suborigin-policy-option">suborigin-policy-option</a><span>, in §3.5</span>
   <li><a href="#xhr">XHR</a><span>, in §2</span>
   <li><a href="#xmlhttprequest">XMLHttpRequest</a><span>, in §2</span>
   <li><a href="#xss">XSS</a><span>, in §2</span>
  </ul>
  <aside class="dfn-panel" data-for="term-for-cross-origin-request-with-preflight-0">
   <a href="https://www.w3.org/TR/cors#cross-origin-request-with-preflight-0">https://www.w3.org/TR/cors#cross-origin-request-with-preflight-0</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cross-origin-request-with-preflight-0">4.1. CORS</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-simple-cross-origin-request">
   <a href="https://www.w3.org/TR/cors#simple-cross-origin-request">https://www.w3.org/TR/cors#simple-cross-origin-request</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-simple-cross-origin-request">4.1. CORS</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-document">
   <a href="https://dom.spec.whatwg.org/#document">https://dom.spec.whatwg.org/#document</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-document">5.1. Storage</a>
    <li><a href="#ref-for-document①">6.2.1. Cookies</a> <a href="#ref-for-document②">(2)</a> <a href="#ref-for-document③">(3)</a> <a href="#ref-for-document④">(4)</a> <a href="#ref-for-document⑤">(5)</a> <a href="#ref-for-document⑥">(6)</a>
    <li><a href="#ref-for-document⑦">6.3.3. 'unsafe-cookies'</a> <a href="#ref-for-document⑧">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-document">
   <a href="https://dom.spec.whatwg.org/#concept-document">https://dom.spec.whatwg.org/#concept-document</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-document">3.7. Accessing the Suborigin in JavaScript</a> <a href="#ref-for-concept-document①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-reflect">
   <a href="https://dom.spec.whatwg.org/#concept-reflect">https://dom.spec.whatwg.org/#concept-reflect</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-reflect">3.7. Accessing the Suborigin in JavaScript</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-credentials">
   <a href="https://fetch.spec.whatwg.org#credentials">https://fetch.spec.whatwg.org#credentials</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-credentials">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-request-credentials-mode">
   <a href="https://fetch.spec.whatwg.org#concept-request-credentials-mode">https://fetch.spec.whatwg.org#concept-request-credentials-mode</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-request-credentials-mode">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-request-current-url">
   <a href="https://fetch.spec.whatwg.org#concept-request-current-url">https://fetch.spec.whatwg.org#concept-request-current-url</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-request-current-url">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-fetch">
   <a href="https://fetch.spec.whatwg.org#concept-fetch">https://fetch.spec.whatwg.org#concept-fetch</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-fetch">4.1. CORS</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-http-network-or-cache-fetch">
   <a href="https://fetch.spec.whatwg.org#http-network-or-cache-fetch">https://fetch.spec.whatwg.org#http-network-or-cache-fetch</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-http-network-or-cache-fetch">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-origin-header">
   <a href="https://fetch.spec.whatwg.org#origin-header">https://fetch.spec.whatwg.org#origin-header</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-origin-header">4.1. CORS</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-request-origin">
   <a href="https://fetch.spec.whatwg.org#concept-request-origin">https://fetch.spec.whatwg.org#concept-request-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-request-origin">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-messageeventsource">
   <a href="https://html.spec.whatwg.org/multipage/comms.html#messageeventsource">https://html.spec.whatwg.org/multipage/comms.html#messageeventsource</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-messageeventsource">4.2. postMessage</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-messageport">
   <a href="https://html.spec.whatwg.org/multipage/web-messaging.html#messageport">https://html.spec.whatwg.org/multipage/web-messaging.html#messageport</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-messageport">4.2. postMessage</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-storage-2">
   <a href="https://html.spec.whatwg.org/multipage/webstorage.html#storage-2">https://html.spec.whatwg.org/multipage/webstorage.html#storage-2</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-storage-2">5.1. Storage</a> <a href="#ref-for-storage-2①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-window">
   <a href="https://html.spec.whatwg.org/multipage/window-object.html#window">https://html.spec.whatwg.org/multipage/window-object.html#window</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-window">4.2. postMessage</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-ascii-serialisation-of-an-origin">
   <a href="https://html.spec.whatwg.org/multipage/#ascii-serialisation-of-an-origin">https://html.spec.whatwg.org/multipage/#ascii-serialisation-of-an-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-ascii-serialisation-of-an-origin">6.1.6.2. ASCII Serialization of a Suborigin</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-attr-meta-http-equiv-set-cookie">
   <a href="https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-set-cookie">https://html.spec.whatwg.org/multipage/#attr-meta-http-equiv-set-cookie</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-attr-meta-http-equiv-set-cookie">6.2.1. Cookies</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-environment-settings-object">
   <a href="https://html.spec.whatwg.org/multipage/comms.html#environment-settings-object">https://html.spec.whatwg.org/multipage/comms.html#environment-settings-object</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-environment-settings-object">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-dom-localstorage">
   <a href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage">https://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-dom-localstorage">5.1. Storage</a> <a href="#ref-for-dom-localstorage①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-origin">
   <a href="https://html.spec.whatwg.org/multipage/#concept-origin">https://html.spec.whatwg.org/multipage/#concept-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-origin">3.2. Threat Model</a>
    <li><a href="#ref-for-concept-origin①">5.1. Storage</a> <a href="#ref-for-concept-origin②">(2)</a>
    <li><a href="#ref-for-concept-origin③">6.1. Updates to Origin</a>
    <li><a href="#ref-for-concept-origin④">6.1.2. Origin Tuple</a>
    <li><a href="#ref-for-concept-origin⑤">6.1.3. Physical Origin</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-origin-tuple">
   <a href="https://html.spec.whatwg.org/multipage/#concept-origin-tuple">https://html.spec.whatwg.org/multipage/#concept-origin-tuple</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-origin-tuple">6.1.2. Origin Tuple</a>
    <li><a href="#ref-for-concept-origin-tuple①">6.1.3. Physical Origin</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-dom-messageport-postmessage">
   <a href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage">https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-dom-messageport-postmessage">1. Introduction</a>
    <li><a href="#ref-for-dom-messageport-postmessage①">4. Access Control</a>
    <li><a href="#ref-for-dom-messageport-postmessage②">4.2. postMessage</a> <a href="#ref-for-dom-messageport-postmessage③">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-same-origin">
   <a href="https://html.spec.whatwg.org/multipage/origin.html#same-origin">https://html.spec.whatwg.org/multipage/origin.html#same-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-same-origin②">6.1.4. Comparing Origins</a>
    <li><a href="#ref-for-same-origin③">6.1.5. Comparing Physical Origins</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-same-origin">
   <a href="https://html.spec.whatwg.org/multipage/#same-origin">https://html.spec.whatwg.org/multipage/#same-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-same-origin">3. Defining a Suborigin</a> <a href="#ref-for-same-origin①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-dom-sessionstorage">
   <a href="https://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage">https://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-dom-sessionstorage">5.1. Storage</a> <a href="#ref-for-dom-sessionstorage①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-origin-tuple">
   <a href="https://html.spec.whatwg.org/multipage/#concept-origin-tuple">https://html.spec.whatwg.org/multipage/#concept-origin-tuple</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-origin-tuple">6.1.2. Origin Tuple</a>
    <li><a href="#ref-for-concept-origin-tuple①">6.1.3. Physical Origin</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-unicode-serialisation-of-an-origin">
   <a href="https://html.spec.whatwg.org/multipage/#unicode-serialisation-of-an-origin">https://html.spec.whatwg.org/multipage/#unicode-serialisation-of-an-origin</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-unicode-serialisation-of-an-origin">6.1.6.1. Unicode Serialization of a Suborigin</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-cookie-averse">
   <a href="http://www.w3.org/TR/html51/dom.html#cookie-averse">http://www.w3.org/TR/html51/dom.html#cookie-averse</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cookie-averse">6.2.1. Cookies</a> <a href="#ref-for-cookie-averse①">(2)</a> <a href="#ref-for-cookie-averse②">(3)</a> <a href="#ref-for-cookie-averse③">(4)</a>
    <li><a href="#ref-for-cookie-averse④">6.3.3. 'unsafe-cookies'</a> <a href="#ref-for-cookie-averse⑤">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-resource-metadata-management">
   <a href="http://www.w3.org/TR/html51/dom.html#resource-metadata-management">http://www.w3.org/TR/html51/dom.html#resource-metadata-management</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-resource-metadata-management">6.2.1. Cookies</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-section-3.2.3">
   <a href="https://tools.ietf.org/html/rfc7230#section-3.2.3">https://tools.ietf.org/html/rfc7230#section-3.2.3</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-section-3.2.3">3.5. The suborigin header</a> <a href="#ref-for-section-3.2.3①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-section-3.2.3">
   <a href="https://tools.ietf.org/html/rfc7230#section-3.2.3">https://tools.ietf.org/html/rfc7230#section-3.2.3</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-section-3.2.3">3.5. The suborigin header</a> <a href="#ref-for-section-3.2.3①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-appendix-B.1">
   <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">https://tools.ietf.org/html/rfc5234#appendix-B.1</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-appendix-B.1">2.1. Grammatical Concepts</a>
    <li><a href="#ref-for-appendix-B.1①">3.5. The suborigin header</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-appendix-B.1">
   <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">https://tools.ietf.org/html/rfc5234#appendix-B.1</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-appendix-B.1">2.1. Grammatical Concepts</a>
    <li><a href="#ref-for-appendix-B.1①">3.5. The suborigin header</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-domain">
   <a href="https://url.spec.whatwg.org/#concept-domain">https://url.spec.whatwg.org/#concept-domain</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-domain">6.1.2. Origin Tuple</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-host">
   <a href="https://url.spec.whatwg.org/#concept-host">https://url.spec.whatwg.org/#concept-host</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-host">3. Defining a Suborigin</a> <a href="#ref-for-concept-host①">(2)</a>
    <li><a href="#ref-for-concept-host②">3.6. Representation of Suborigins</a>
    <li><a href="#ref-for-concept-host③">6.1.2. Origin Tuple</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-port">
   <a href="https://url.spec.whatwg.org/#concept-port">https://url.spec.whatwg.org/#concept-port</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-port">3. Defining a Suborigin</a> <a href="#ref-for-concept-port①">(2)</a>
    <li><a href="#ref-for-concept-port②">3.6. Representation of Suborigins</a>
    <li><a href="#ref-for-concept-port③">6.1.2. Origin Tuple</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-concept-scheme">
   <a href="https://url.spec.whatwg.org/#concept-scheme">https://url.spec.whatwg.org/#concept-scheme</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-concept-scheme">3. Defining a Suborigin</a> <a href="#ref-for-concept-scheme①">(2)</a>
    <li><a href="#ref-for-concept-scheme②">3.6. Representation of Suborigins</a>
    <li><a href="#ref-for-concept-scheme③">6.1.2. Origin Tuple</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-idl-DOMString">
   <a href="https://heycam.github.io/webidl/#idl-DOMString">https://heycam.github.io/webidl/#idl-DOMString</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-idl-DOMString">4.2. postMessage</a> <a href="#ref-for-idl-DOMString①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-idl-USVString">
   <a href="https://heycam.github.io/webidl/#idl-USVString">https://heycam.github.io/webidl/#idl-USVString</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-idl-USVString">4.2. postMessage</a> <a href="#ref-for-idl-USVString①">(2)</a> <a href="#ref-for-idl-USVString②">(3)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-idl-boolean">
   <a href="https://heycam.github.io/webidl/#idl-boolean">https://heycam.github.io/webidl/#idl-boolean</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-idl-boolean">4.2. postMessage</a> <a href="#ref-for-idl-boolean①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-idl-object">
   <a href="https://heycam.github.io/webidl/#idl-object">https://heycam.github.io/webidl/#idl-object</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-idl-object">4.2. postMessage</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="term-for-the-withcredentials-attribute">
   <a href="https://xhr.spec.whatwg.org/#the-withcredentials-attribute">https://xhr.spec.whatwg.org/#the-withcredentials-attribute</a><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-the-withcredentials-attribute">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <h3 class="no-num no-ref heading settled" id="index-defined-elsewhere"><span class="content">Terms defined by reference</span><a class="self-link" href="#index-defined-elsewhere"></a></h3>
  <ul class="index">
   <li>
    <a data-link-type="biblio">[CORS]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-cross-origin-request-with-preflight-0" style="color:initial">cross-origin request with preflight</span>
     <li><span class="dfn-paneled" id="term-for-simple-cross-origin-request" style="color:initial">simple cross-origin request</span>
    </ul>
   <li>
    <a data-link-type="biblio">[DOM]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-document" style="color:initial">Document</span>
     <li><span class="dfn-paneled" id="term-for-concept-document" style="color:initial">document</span>
     <li><span class="dfn-paneled" id="term-for-concept-reflect" style="color:initial">reflect</span>
    </ul>
   <li>
    <a data-link-type="biblio">[FETCH]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-credentials" style="color:initial">credentials</span>
     <li><span class="dfn-paneled" id="term-for-concept-request-credentials-mode" style="color:initial">credentials mode</span>
     <li><span class="dfn-paneled" id="term-for-concept-request-current-url" style="color:initial">current url</span>
     <li><span class="dfn-paneled" id="term-for-concept-fetch" style="color:initial">fetch</span>
     <li><span class="dfn-paneled" id="term-for-http-network-or-cache-fetch" style="color:initial">http-network-or-cache fetch</span>
     <li><span class="dfn-paneled" id="term-for-origin-header" style="color:initial">origin header</span>
     <li><span class="dfn-paneled" id="term-for-concept-request-origin" style="color:initial">request origin</span>
    </ul>
   <li>
    <a data-link-type="biblio">[HTML]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-messageeventsource" style="color:initial">MessageEventSource</span>
     <li><span class="dfn-paneled" id="term-for-messageport" style="color:initial">MessagePort</span>
     <li><span class="dfn-paneled" id="term-for-storage-2" style="color:initial">Storage</span>
     <li><span class="dfn-paneled" id="term-for-window" style="color:initial">Window</span>
     <li><span class="dfn-paneled" id="term-for-ascii-serialisation-of-an-origin" style="color:initial">ascii serialization of an origin</span>
     <li><span class="dfn-paneled" id="term-for-attr-meta-http-equiv-set-cookie" style="color:initial">cookie setter</span>
     <li><span class="dfn-paneled" id="term-for-environment-settings-object" style="color:initial">environment settings object</span>
     <li><span class="dfn-paneled" id="term-for-dom-localstorage" style="color:initial">localStorage</span>
     <li><span class="dfn-paneled" id="term-for-concept-origin" style="color:initial">origin</span>
     <li><span class="dfn-paneled" id="term-for-concept-origin-tuple" style="color:initial">origin tuple</span>
     <li><span class="dfn-paneled" id="term-for-dom-messageport-postmessage" style="color:initial">postmessage</span>
     <li><span class="dfn-paneled" id="term-for-same-origin" style="color:initial">same origin</span>
     <li><span class="dfn-paneled" id="term-for-same-origin①" style="color:initial">same-origin</span>
     <li><span class="dfn-paneled" id="term-for-dom-sessionstorage" style="color:initial">sessionStorage</span>
     <li><span class="dfn-paneled" id="term-for-concept-origin-tuple①" style="color:initial">tuple origin</span>
     <li><span class="dfn-paneled" id="term-for-unicode-serialisation-of-an-origin" style="color:initial">unicode serialization of an origin</span>
    </ul>
   <li>
    <a data-link-type="biblio">[html51]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-cookie-averse" style="color:initial">cookie-averse</span>
     <li><span class="dfn-paneled" id="term-for-resource-metadata-management" style="color:initial">resource metadata management</span>
    </ul>
   <li>
    <a data-link-type="biblio">[http]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-section-3.2.3" style="color:initial">ows</span>
     <li><span class="dfn-paneled" id="term-for-section-3.2.3①" style="color:initial">rws</span>
    </ul>
   <li>
    <a data-link-type="biblio">[RFC5234]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-appendix-B.1" style="color:initial">alpha</span>
     <li><span class="dfn-paneled" id="term-for-appendix-B.1①" style="color:initial">digit</span>
    </ul>
   <li>
    <a data-link-type="biblio">[URL]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-concept-domain" style="color:initial">domain</span>
     <li><span class="dfn-paneled" id="term-for-concept-host" style="color:initial">host</span>
     <li><span class="dfn-paneled" id="term-for-concept-port" style="color:initial">port</span>
     <li><span class="dfn-paneled" id="term-for-concept-scheme" style="color:initial">scheme</span>
    </ul>
   <li>
    <a data-link-type="biblio">[WebIDL]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-idl-DOMString" style="color:initial">DOMString</span>
     <li><span class="dfn-paneled" id="term-for-idl-USVString" style="color:initial">USVString</span>
     <li><span class="dfn-paneled" id="term-for-idl-boolean" style="color:initial">boolean</span>
     <li><span class="dfn-paneled" id="term-for-idl-object" style="color:initial">object</span>
    </ul>
   <li>
    <a data-link-type="biblio">[XHR]</a> defines the following terms:
    <ul>
     <li><span class="dfn-paneled" id="term-for-the-withcredentials-attribute" style="color:initial">withcredentials</span>
    </ul>
  </ul>
  <h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
  <h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
  <dl>
   <dt id="biblio-cors">[CORS]
   <dd>Anne van Kesteren. <a href="https://www.w3.org/TR/cors/">Cross-Origin Resource Sharing</a>. 16 January 2014. REC. URL: <a href="https://www.w3.org/TR/cors/">https://www.w3.org/TR/cors/</a>
   <dt id="biblio-dom">[DOM]
   <dd>Anne van Kesteren. <a href="https://dom.spec.whatwg.org/">DOM Standard</a>. Living Standard. URL: <a href="https://dom.spec.whatwg.org/">https://dom.spec.whatwg.org/</a>
   <dt id="biblio-fetch">[FETCH]
   <dd>Anne van Kesteren. <a href="https://fetch.spec.whatwg.org/">Fetch Standard</a>. Living Standard. URL: <a href="https://fetch.spec.whatwg.org/">https://fetch.spec.whatwg.org/</a>
   <dt id="biblio-html">[HTML]
   <dd>Anne van Kesteren; et al. <a href="https://html.spec.whatwg.org/multipage/">HTML Standard</a>. Living Standard. URL: <a href="https://html.spec.whatwg.org/multipage/">https://html.spec.whatwg.org/multipage/</a>
   <dt id="biblio-html51">[HTML51]
   <dd>Steve Faulkner; et al. <a href="https://www.w3.org/TR/html51/">HTML 5.1 2nd Edition</a>. 3 October 2017. REC. URL: <a href="https://www.w3.org/TR/html51/">https://www.w3.org/TR/html51/</a>
   <dt id="biblio-rfc0020">[RFC0020]
   <dd>V.G. Cerf. <a href="https://tools.ietf.org/html/rfc20">ASCII format for network interchange</a>. October 1969. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc20">https://tools.ietf.org/html/rfc20</a>
   <dt id="biblio-rfc2119">[RFC2119]
   <dd>S. Bradner. <a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>. March 1997. Best Current Practice. URL: <a href="https://tools.ietf.org/html/rfc2119">https://tools.ietf.org/html/rfc2119</a>
   <dt id="biblio-rfc5234">[RFC5234]
   <dd>D. Crocker, Ed.; P. Overell. <a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>. January 2008. Internet Standard. URL: <a href="https://tools.ietf.org/html/rfc5234">https://tools.ietf.org/html/rfc5234</a>
   <dt id="biblio-unicode6">[Unicode6]
   <dd>The Unicode Consortium. <a href="https://www.unicode.org/versions/Unicode6.2.0/">The Unicode Standard, Version 6.2.0</a>. URL: <a href="https://www.unicode.org/versions/Unicode6.2.0/">https://www.unicode.org/versions/Unicode6.2.0/</a>
   <dt id="biblio-url">[URL]
   <dd>Anne van Kesteren. <a href="https://url.spec.whatwg.org/">URL Standard</a>. Living Standard. URL: <a href="https://url.spec.whatwg.org/">https://url.spec.whatwg.org/</a>
   <dt id="biblio-webidl">[WebIDL]
   <dd>Boris Zbarsky. <a href="https://heycam.github.io/webidl/">Web IDL</a>. 15 December 2016. ED. URL: <a href="https://heycam.github.io/webidl/">https://heycam.github.io/webidl/</a>
   <dt id="biblio-websockets">[WebSockets]
   <dd>Ian Hickson. <a href="https://www.w3.org/TR/websockets/">The WebSocket API</a>. 20 September 2012. CR. URL: <a href="https://www.w3.org/TR/websockets/">https://www.w3.org/TR/websockets/</a>
   <dt id="biblio-workers">[WORKERS]
   <dd>Ian Hickson. <a href="https://www.w3.org/TR/workers/">Web Workers</a>. 24 September 2015. WD. URL: <a href="https://www.w3.org/TR/workers/">https://www.w3.org/TR/workers/</a>
   <dt id="biblio-xhr">[XHR]
   <dd>Anne van Kesteren. <a href="https://xhr.spec.whatwg.org/">XMLHttpRequest Standard</a>. Living Standard. URL: <a href="https://xhr.spec.whatwg.org/">https://xhr.spec.whatwg.org/</a>
  </dl>
  <h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
  <dl>
   <dt id="biblio-csp2">[CSP2]
   <dd>Mike West; Adam Barth; Daniel Veditz. <a href="https://www.w3.org/TR/CSP2/">Content Security Policy Level 2</a>. 15 December 2016. REC. URL: <a href="https://www.w3.org/TR/CSP2/">https://www.w3.org/TR/CSP2/</a>
   <dt id="biblio-iframesandbox">[IFrameSandbox]
   <dd>Mike West. <a href="http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/">Play safely in sandboxed IFrames</a>. URL: <a href="http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/">http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/</a>
   <dt id="biblio-privilegeseparation">[PRIVILEGESEPARATION]
   <dd>Devdatta Akhawe; Prateek Saxena; Dawn Song. <a href="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final168.pdf">Privilege Separation in HTML5 Applications</a>. URL: <a href="https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final168.pdf">https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final168.pdf</a>
   <dt id="biblio-rfc6454">[RFC6454]
   <dd>A. Barth. <a href="https://tools.ietf.org/html/rfc6454">The Web Origin Concept</a>. December 2011. Proposed Standard. URL: <a href="https://tools.ietf.org/html/rfc6454">https://tools.ietf.org/html/rfc6454</a>
  </dl>
  <h2 class="no-num no-ref heading settled" id="idl-index"><span class="content">IDL Index</span><a class="self-link" href="#idl-index"></a></h2>
<pre class="idl highlight def"><c- b>dictionary</c-> <a href="#dictdef-extendedorigin"><code><c- g>ExtendedOrigin</c-></code></a> {
  <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString③"><c- b>USVString</c-></a> <a data-default="&quot;&quot;" data-type="USVString " href="#dom-extendedorigin-origin"><code><c- g>origin</c-></code></a> = "";
  <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString①①"><c- b>USVString</c-></a>? <a data-default="null" data-type="USVString? " href="#dom-extendedorigin-suborigin"><code><c- g>suborigin</c-></code></a> = <c- b>null</c->;
};

<c- b>interface</c-> <a href="#messageevent"><code><c- g>MessageEvent</c-></code></a> {
  <c- b>readonly</c-> <c- b>attribute</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-USVString" id="ref-for-idl-USVString②①"><c- b>USVString</c-></a>? <a data-readonly data-type="USVString?" href="#dom-messageevent-origin"><code><c- g>origin</c-></code></a>;
  <c- b>readonly</c-> <c- b>attribute</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin④"><c- n>ExtendedOrigin</c-></a> <a data-readonly data-type="ExtendedOrigin" href="#dom-messageevent-extendedorigin"><code><c- g>extendedOrigin</c-></code></a>;
  <c- b>void</c-> <a href="#dom-messageevent-initmessageevent"><code><c- g>initMessageEvent</c-></code></a>(<a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-DOMString" id="ref-for-idl-DOMString②"><c- b>DOMString</c-></a> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-type"><code><c- g>type</c-></code></a>, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-boolean" id="ref-for-idl-boolean②"><c- b>boolean</c-></a> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-bubbles"><code><c- g>bubbles</c-></code></a> = <c- b>false</c->, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-boolean" id="ref-for-idl-boolean①①"><c- b>boolean</c-></a> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-cancelable"><code><c- g>cancelable</c-></code></a> = <c- b>false</c->, <c- b>optional</c-> <c- b>any</c-> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-data"><code><c- g>data</c-></code></a> = <c- b>null</c->, <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin①①"><c- n>ExtendedOrigin</c-></a>? <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-extendedorigin"><code><c- g>extendedOrigin</c-></code></a> = <c- b>null</c->, <c- b>optional</c-> <a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-DOMString" id="ref-for-idl-DOMString①①"><c- b>DOMString</c-></a> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-lasteventid"><code><c- g>lastEventId</c-></code></a> = "", <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="https://html.spec.whatwg.org/multipage/comms.html#messageeventsource" id="ref-for-messageeventsource①"><c- n>MessageEventSource</c-></a>? <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-source"><code><c- g>source</c-></code></a> = <c- b>null</c->, <c- b>optional</c-> <c- b>sequence</c->&lt;<a class="n" data-link-type="idl-name" href="https://html.spec.whatwg.org/multipage/web-messaging.html#messageport" id="ref-for-messageport①"><c- n>MessagePort</c-></a>> <a href="#dom-messageevent-initmessageevent-type-bubbles-cancelable-data-extendedorigin-lasteventid-source-ports-ports"><code><c- g>ports</c-></code></a> = []);
};

<c- b>dictionary</c-> <a href="#dictdef-messageeventinit"><code><c- g>MessageEventInit</c-></code></a> {
  <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin②①"><c- n>ExtendedOrigin</c-></a>? <a data-default="null" data-type="ExtendedOrigin? " href="#dom-messageeventinit-extendedorigin"><code><c- g>extendedOrigin</c-></code></a> = <c- b>null</c->;
};

<c- b>partial</c-> <c- b>interface</c-> <a class="idl-code" data-link-type="interface" href="https://html.spec.whatwg.org/multipage/window-object.html#window" id="ref-for-window①"><c- g>Window</c-></a> {
  <c- b>void</c-> <a href="#dom-window-postmessage"><code><c- g>postMessage</c-></code></a>(<c- b>any</c-> <a href="#dom-window-postmessage-message-targetorigin-transfer-message"><code><c- g>message</c-></code></a>, <c- b>optional</c-> <a class="n" data-link-type="idl-name" href="#dictdef-extendedorigin" id="ref-for-dictdef-extendedorigin③①"><c- n>ExtendedOrigin</c-></a> <a href="#dom-window-postmessage-message-targetorigin-transfer-targetorigin"><code><c- g>targetOrigin</c-></code></a>, <c- b>optional</c-> <c- b>sequence</c->&lt;<a class="idl-code" data-link-type="interface" href="https://heycam.github.io/webidl/#idl-object" id="ref-for-idl-object①"><c- b>object</c-></a>> <a href="#dom-window-postmessage-message-targetorigin-transfer-transfer"><code><c- g>transfer</c-></code></a> = []);
};

</pre>
  <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content">Issues Index</span><a class="self-link" href="#issues-index"></a></h2>
  <div style="counter-reset:issue">
   <div class="issue"> TODO: We probably should add additional examples, or perhaps match an
  example to each bullet above.<a href="#issue-21aaf26d"> ↵ </a></div>
   <div class="issue"> TODO(jww) This needs to be filled in once we have a pretty good handle on
  the basic structure of this document. At that point, we should extract the terms
  defined throughout the spec and place them here.<a href="#issue-7af0036e"> ↵ </a></div>
   <div class="issue"> TODO(devd): Should we also assert that attacker on main/parent origin
  cannot compromise the app in sub-origin?<a href="#issue-4b8e74eb"> ↵ </a></div>
   <div class="issue"> "Should not control" is a stronger statement than I think we want to
  make. The browser can only isolate per origin isolation. If the app has a bug
  (due to postmessage or server-side) the browser can’t do anything. We should
  stick to saying "are isolated like physical origins."<a href="#issue-df2253b2"> ↵ </a></div>
   <div class="issue"> TODO: Determine how the serialization should relate to the URL spec:
  https://url.spec.whatwg.org/#host-parsing<a href="#issue-f67832ce"> ↵ </a></div>
   <div class="issue"> TODO(jww): Need to write the formal IDL for this.<a href="#issue-1dbd01cb"> ↵ </a></div>
   <div class="issue"> TODO(devd): Making things specific to XHR or CORS is weird. We should
  just make all fetches inside a suborigin CORS fetches and be done with it.<a href="#issue-4f0009c4"> ↵ </a></div>
   <div class="issue"> TODO(jww): Formal definition of the headers and responses w/grammars.
  Also need to be explicit about <code>*</code> having same limitations as <code>Access-Control-Allow-Origin</code> w/credentials.<a href="#issue-5b3d4495"> ↵ </a></div>
   <div class="issue"> Access-Control-Allow-Origin * fails with credentialed requests. Does
  Access-Control-Allow-Suborigin have the same behavior? We should detail that
  in more detail.<a href="#issue-6750573e"> ↵ </a></div>
   <div class="issue"> Browsers have a really low cache time (15mins) for preflight responses
  which makes CORS a big pain for websites. This will become even more salient
  with suborigins. Should the spec ask browsers to increase cache times?<a href="#issue-5be18446"> ↵ </a></div>
   <div class="issue"> Serializing the suborigin value into the origin header seems like it
  will break things. Whats the risk with serializing the physical origin in the
  origin header? The browser won’t let you read the responses (or succeed
  preflight) if neither of them have the right allow-suborigin behavior. This
  seems more compatible with no security risk.<a href="#issue-aedb28e2"> ↵ </a></div>
   <div class="issue"> We’re monkey-patching HTML, submit a PR when we’re sure this is the
  general direction we want to go in.<a href="#issue-c9cb881f"> ↵ </a></div>
   <div class="issue"> TODO(jww): Formalize by updating the <a data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/comms.html#dom-messageport-postmessage">postMessage</a> algorithm<a href="#issue-ebe2c3d2"> ↵ </a></div>
   <div class="issue"> TODO: Formalize. Not sure what this will look like yet. Chrome and
  Opera don’t allow creation of workers from sandbox’d iframes/the 'null'
  origin, but not sure if this formalized in a spec. If it is, should probably
  just update whatever disallows creation from sandbox.<a href="#issue-3fffd8fc"> ↵ </a></div>
   <div class="issue"> Currently, some browsers do not let applications redefine getters and
  setters on cookie averse documents. Should the spec enforce that this is
  allowed?<a href="#issue-90521f50"> ↵ </a></div>
   <div class="issue"> TODO(jww,aaj): Provide an example of why this might be needed.<a href="#issue-ec925137"> ↵ </a></div>
   <div class="issue"> TODO: These opt-out descriptions should probably be moved to the
  individual sections where the behaviors are discussed (i.e. postMessage and
  cookies). These just need to be fleshed out anyway, and examples and reasons
  need to be given. Also, they need to update the processing model, such as
  adding appropriate flags to the environment settings object.<a href="#issue-9b7d04a5"> ↵ </a></div>
   <div class="issue"> TODO(devd): Flesh out the above and make sure it covers all it needs to
  cover.<a href="#issue-810c1065"> ↵ </a></div>
   <div class="issue"> Is history.pushState allowed in a suborigin? I suggest no to reduce
  complexity and inherit from sandbox behavior. On the other hand, this impacts
  compatibility.<a href="#issue-d4f11cd7"> ↵ </a></div>
   <div class="issue"> TODO: Need to list concerns with serialization, e.g. apps that don’t
  recognize the suborigin serialization, esp. if they blocklist origins.<a href="#issue-d8492fe3"> ↵ </a></div>
   <div class="issue"> TODO: Do we have privacy issues?<a href="#issue-747044d5"> ↵ </a></div>
  </div>
  <aside class="dfn-panel" data-for="cors">
   <b><a href="#cors">#cors</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-cors">1. Introduction</a>
    <li><a href="#ref-for-cors①">4. Access Control</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="xmlhttprequest">
   <b><a href="#xmlhttprequest">#xmlhttprequest</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-xmlhttprequest">4.1. CORS</a>
    <li><a href="#ref-for-xmlhttprequest①">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="xss">
   <b><a href="#xss">#xss</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-xss">3.2.1. Cross-Document Attacker</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="grammardef-loweralpha">
   <b><a href="#grammardef-loweralpha">#grammardef-loweralpha</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-grammardef-loweralpha">3.5. The suborigin header</a> <a href="#ref-for-grammardef-loweralpha①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="suborigin">
   <b><a href="#suborigin">#suborigin</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-suborigin">5.3. WebSockets</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="grammardef-suborigin-name">
   <b><a href="#grammardef-suborigin-name">#grammardef-suborigin-name</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-grammardef-suborigin-name">3.5. The suborigin header</a> <a href="#ref-for-grammardef-suborigin-name①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="grammardef-suborigin-policy-option">
   <b><a href="#grammardef-suborigin-policy-option">#grammardef-suborigin-policy-option</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-grammardef-suborigin-policy-option">3.5. The suborigin header</a> <a href="#ref-for-grammardef-suborigin-policy-option①">(2)</a>
    <li><a href="#ref-for-grammardef-suborigin-policy-option②">6.2.1. Cookies</a>
    <li><a href="#ref-for-grammardef-suborigin-policy-option③">6.3. Security Model Opt-Outs</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="grammardef-suborigin-policy-list">
   <b><a href="#grammardef-suborigin-policy-list">#grammardef-suborigin-policy-list</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-grammardef-suborigin-policy-list">3.5. The suborigin header</a> <a href="#ref-for-grammardef-suborigin-policy-list①">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="suborigin-namespace">
   <b><a href="#suborigin-namespace">#suborigin-namespace</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-suborigin-namespace">3. Defining a Suborigin</a> <a href="#ref-for-suborigin-namespace①">(2)</a>
    <li><a href="#ref-for-suborigin-namespace②">3.6. Representation of Suborigins</a> <a href="#ref-for-suborigin-namespace③">(2)</a>
    <li><a href="#ref-for-suborigin-namespace④">5.1. Storage</a> <a href="#ref-for-suborigin-namespace⑤">(2)</a>
    <li><a href="#ref-for-suborigin-namespace⑥">6.1.2. Origin Tuple</a>
    <li><a href="#ref-for-suborigin-namespace⑦">6.2.1. Cookies</a> <a href="#ref-for-suborigin-namespace⑧">(2)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="suborigin-policy">
   <b><a href="#suborigin-policy">#suborigin-policy</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-suborigin-policy">6.2.1. Cookies</a>
    <li><a href="#ref-for-suborigin-policy①">6.3. Security Model Opt-Outs</a> <a href="#ref-for-suborigin-policy②">(2)</a>
    <li><a href="#ref-for-suborigin-policy③">6.3.3. 'unsafe-cookies'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="dictdef-extendedorigin">
   <b><a href="#dictdef-extendedorigin">#dictdef-extendedorigin</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-dictdef-extendedorigin">4.2. postMessage</a> <a href="#ref-for-dictdef-extendedorigin①">(2)</a> <a href="#ref-for-dictdef-extendedorigin②">(3)</a> <a href="#ref-for-dictdef-extendedorigin③">(4)</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="physical-origin">
   <b><a href="#physical-origin">#physical-origin</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-physical-origin">3.6. Representation of Suborigins</a>
    <li><a href="#ref-for-physical-origin①">6.1.5. Comparing Physical Origins</a> <a href="#ref-for-physical-origin②">(2)</a>
    <li><a href="#ref-for-physical-origin③">6.2.1. Cookies</a>
    <li><a href="#ref-for-physical-origin④">6.3.3. 'unsafe-cookies'</a>
    <li><a href="#ref-for-physical-origin⑤">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
  <aside class="dfn-panel" data-for="same-physical-origin">
   <b><a href="#same-physical-origin">#same-physical-origin</a></b><b>Referenced in:</b>
   <ul>
    <li><a href="#ref-for-same-physical-origin">6.3.4. 'unsafe-credentials'</a>
   </ul>
  </aside>
<script>/* script-dfn-panel */

document.body.addEventListener("click", function(e) {
    var queryAll = function(sel) { return [].slice.call(document.querySelectorAll(sel)); }
    // Find the dfn element or panel, if any, that was clicked on.
    var el = e.target;
    var target;
    var hitALink = false;
    while(el.parentElement) {
        if(el.tagName == "A") {
            // Clicking on a link in a <dfn> shouldn't summon the panel
            hitALink = true;
        }
        if(el.classList.contains("dfn-paneled")) {
            target = "dfn";
            break;
        }
        if(el.classList.contains("dfn-panel")) {
            target = "dfn-panel";
            break;
        }
        el = el.parentElement;
    }
    if(target != "dfn-panel") {
        // Turn off any currently "on" or "activated" panels.
        queryAll(".dfn-panel.on, .dfn-panel.activated").forEach(function(el){
            el.classList.remove("on");
            el.classList.remove("activated");
        });
    }
    if(target == "dfn" && !hitALink) {
        // open the panel
        var dfnPanel = document.querySelector(".dfn-panel[data-for='" + el.id + "']");
        if(dfnPanel) {
            dfnPanel.classList.add("on");
            var rect = el.getBoundingClientRect();
            dfnPanel.style.left = window.scrollX + rect.right + 5 + "px";
            dfnPanel.style.top = window.scrollY + rect.top + "px";
            var panelRect = dfnPanel.getBoundingClientRect();
            var panelWidth = panelRect.right - panelRect.left;
            if(panelRect.right > document.body.scrollWidth && (rect.left - (panelWidth + 5)) > 0) {
                // Reposition, because the panel is overflowing
                dfnPanel.style.left = window.scrollX + rect.left - (panelWidth + 5) + "px";
            }
        } else {
            console.log("Couldn't find .dfn-panel[data-for='" + el.id + "']");
        }
    } else if(target == "dfn-panel") {
        // Switch it to "activated" state, which pins it.
        el.classList.add("activated");
        el.style.left = null;
        el.style.top = null;
    }

});
</script>